From cabinet@marinescu-medical.ro Thu May 1 04:37:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32533A6EB7; Thu, 1 May 2008 04:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.615 X-Spam-Level: X-Spam-Status: No, score=-71.615 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD68Q2L68aNc; Thu, 1 May 2008 04:37:06 -0700 (PDT) Received: from 84.122.255.165.dyn.user.ono.com (84.122.255.165.dyn.user.ono.com [84.122.255.165]) by core3.amsl.com (Postfix) with SMTP id 0F0A73A6B89; Thu, 1 May 2008 04:36:31 -0700 (PDT) X-Originating-IP: 230.68.48.16 by smtp.84.122.255.165; Thu, 01 May 2008 07:36:35 -0500 Message-ID: From: "Chrystal Brantley" Reply-To: "Chrystal Brantley" To: call-home-bounces@ietf.org Subject: The discreet replica store Date: Thu, 01 May 2008 07:36:35 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit From travel timepieces to sport watches, Mont Blanc sells some of the finest watches in the world, which are also attached to some very big price tags. An easy way to overcome that is by visiting Prestige Replicas, where you can find the finest replica Mont Blanc watches. http://wybivasalid60.blogspot.com/ Made of the best materials, neither you nor anyone for that matter will be able to tell the difference, and you will save a bundle. Prestige Replicas offers fast shipping and protection of your private information, as well as a discount on the purchase of 2 or more watches. Check out Prestige Replicas today and save thousands on the finest Mont Blanc replica watches! http://wybivasalid60.blogspot.com/ From owner-ccamp@ops.ietf.org Thu May 1 15:38:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EDB3A69F0 for ; Thu, 1 May 2008 15:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agqLSM5UgX38 for ; Thu, 1 May 2008 15:38:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EE473A6881 for ; Thu, 1 May 2008 15:38:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrhFH-000Cmn-QQ for ccamp-data@psg.com; Thu, 01 May 2008 22:27:19 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jrh3Q-0003Ri-P3 for ccamp@ops.ietf.org; Thu, 01 May 2008 22:15:15 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 55B983A6D2F; Thu, 1 May 2008 15:15:00 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-09.txt Message-Id: <20080501221501.55B983A6D2F@core3.amsl.com> Date: Thu, 1 May 2008 15:15:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro Filename : draft-ietf-ccamp-gmpls-mln-reqs-09.txt Pages : 25 Date : 2008-5-1 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-1151318.I-D@ietf.org> --NextPart-- From c.pasquet@graphosphere.com Fri May 2 08:53:09 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23913A6C98; Fri, 2 May 2008 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.4 X-Spam-Level: X-Spam-Status: No, score=-71.4 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRtCkSd6bmif; Fri, 2 May 2008 08:53:09 -0700 (PDT) Received: from host167.190-136-158.telecom.net.ar (host167.190-136-158.telecom.net.ar [190.136.158.167]) by core3.amsl.com (Postfix) with SMTP id 9941028C23F; Fri, 2 May 2008 08:52:57 -0700 (PDT) X-Originating-IP: 88.180.229.154 by smtp.190.136.158.167; Fri, 02 May 2008 11:52:59 -0500 Message-ID: From: "Arron Shirley" Reply-To: "Arron Shirley" To: call-home-bounces@ietf.org Subject: Replica watch is a perfect gift Date: Fri, 02 May 2008 11:52:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://tykuzymuzuz75.blogspot.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://tykuzymuzuz75.blogspot.com/ From c6q@alenkascontest.b.tclk.net Fri May 2 22:00:54 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34E13A68FF; Fri, 2 May 2008 22:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.323 X-Spam-Level: X-Spam-Status: No, score=-73.323 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, GB_ROLEX=5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Ro6gWUIS8F; Fri, 2 May 2008 22:00:54 -0700 (PDT) Received: from 179satb4.codetel.net.do (179satb4.codetel.net.do [64.32.123.179]) by core3.amsl.com (Postfix) with SMTP id 1829C3A68A8; Fri, 2 May 2008 21:59:42 -0700 (PDT) X-Originating-IP: 40.48.168.164 by smtp.64.32.123.179; Sat, 03 May 2008 00:59:39 -0500 Message-ID: From: "Susie Grady" Reply-To: "Susie Grady" To: call-home-bounces@ietf.org Subject: Affordable brand name watches Date: Sat, 03 May 2008 00:59:39 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://botowihadok88.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://botowihadok88.blogspot.com/ From c.lefebvre@hexaware.net Sat May 3 11:46:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E4B3A69FF; Sat, 3 May 2008 11:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.565 X-Spam-Level: X-Spam-Status: No, score=-56.565 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzHxVjo8LOYo; Sat, 3 May 2008 11:46:14 -0700 (PDT) Received: from pc-40-119-47-190.cm.vtr.net (pc-40-119-47-190.cm.vtr.net [190.47.119.40]) by core3.amsl.com (Postfix) with SMTP id EDBE43A692A; Sat, 3 May 2008 11:45:54 -0700 (PDT) X-Originating-IP: 128.167.252.90 by smtp.190.47.119.40; Sat, 03 May 2008 14:45:57 -0500 Message-ID: From: "Fred Shipman" Reply-To: "Fred Shipman" To: call-home-bounces@ietf.org Subject: New replica watches delivered fast Date: Sat, 03 May 2008 14:45:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit How about making your friends jealous and saving a lot of money doing it? Forget about spending thousands of dollars on a new Rolex watch! Instead, visit the newly redesigned Prestige Replicas and buy yourself a beautiful, one of a kind Rolex Datejust watch! http://donovycudix16.blogspot.com/ Of course, we're talking about replica watches, not the overpriced originals... After all, our Rolex Datejusts offer the same precise functionality and exact look than their costly counterparts, but you can buy yours for just a couple of hundred bucks. So, come aboard Prestige Replicas and take advantage of our extensive collection of replica Rolex watches, our superb customer service and our super low prices! http://donovycudix16.blogspot.com/ From maynardantisepsis5480387@yahoo.com Sat May 3 12:14:42 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF573A6DFB; Sat, 3 May 2008 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.677 X-Spam-Level: X-Spam-Status: No, score=-86.677 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg3mxzIPUlLS; Sat, 3 May 2008 12:14:34 -0700 (PDT) Received: from 089-100-118159.ntlworld.ie (unknown [89.100.118.159]) by core3.amsl.com (Postfix) with SMTP id 2AF4628C22A; Sat, 3 May 2008 12:13:39 -0700 (PDT) X-Originating-IP: 32.240.106.208 by smtp.89.100.118.159; Sat, 03 May 2008 15:13:42 -0500 Message-ID: From: "Bobbi Kern" Reply-To: "Bobbi Kern" To: call-home-bounces@ietf.org Subject: Why get an original watch? Date: Sat, 03 May 2008 15:13:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://lodyrytaryw50.blogspot.com/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://lodyrytaryw50.blogspot.com/ From edbishareen2034610@gmail.com Sun May 4 03:10:43 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0A33A6EFE; Sun, 4 May 2008 03:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.839 X-Spam-Level: X-Spam-Status: No, score=-65.839 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA6AxN57Xu+X; Sun, 4 May 2008 03:10:39 -0700 (PDT) Received: from cm-81-9-166-107.telecable.es (cm-81-9-166-107.telecable.es [81.9.166.107]) by core3.amsl.com (Postfix) with SMTP id 450C03A6EF2; Sun, 4 May 2008 03:10:25 -0700 (PDT) X-Originating-IP: 136.129.0.240 by smtp.81.9.166.107; Sun, 04 May 2008 06:10:33 -0500 Message-ID: From: "Chance Calderon" Reply-To: "Chance Calderon" To: call-home-bounces@ietf.org Subject: Save 80% on Brand name replica watches Date: Sun, 04 May 2008 06:10:33 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://fekegiwoked61.blogspot.com/ From rutledgesacrorectal8904682@yahoo.com Sun May 4 13:43:59 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AAF3A698A; Sun, 4 May 2008 13:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.732 X-Spam-Level: X-Spam-Status: No, score=-62.732 tagged_above=-999 required=5 tests=[FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.509, RCVD_IN_XBL=2.896, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.617, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gao2rkEB8IPY; Sun, 4 May 2008 13:43:59 -0700 (PDT) Received: from 190-172-138-25.speedy.com.ar (unknown [190.172.138.25]) by core3.amsl.com (Postfix) with SMTP id 4879B3A6A8E; Sun, 4 May 2008 13:43:47 -0700 (PDT) X-Originating-IP: 21.148.232.32 by smtp.190.172.138.25; Sun, 04 May 2008 16:43:55 -0500 Message-ID: From: "Jonathan Robbins" Reply-To: "Jonathan Robbins" To: call-home-bounces@ietf.org Subject: Why get an original watch? Date: Sun, 04 May 2008 16:43:55 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://migicytyxuf16.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://migicytyxuf16.blogspot.com/ From rodgesensibly9334926@gmail.com Sun May 4 14:00:01 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23E33A6F49; Sun, 4 May 2008 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -63.766 X-Spam-Level: X-Spam-Status: No, score=-63.766 tagged_above=-999 required=5 tests=[FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.617, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqbiYcKGvI50; Sun, 4 May 2008 13:59:59 -0700 (PDT) Received: from 120-0-246-201.adsl.terra.cl (120-0-246-201.adsl.terra.cl [201.246.0.120]) by core3.amsl.com (Postfix) with SMTP id 7EAFC3A6F66; Sun, 4 May 2008 13:58:11 -0700 (PDT) X-Originating-IP: 4.74.48.178 by smtp.201.246.0.120; Sun, 04 May 2008 16:58:19 -0500 Message-ID: From: "Vern Yarbrough" Reply-To: "Vern Yarbrough" To: call-home-bounces@ietf.org Subject: Replica watches made easy Date: Sun, 04 May 2008 16:58:19 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://dyramanevyx16.blogspot.com/ From alphonsorigadoon5257105@yahoo.com Mon May 5 05:29:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97D73A6CB9; Mon, 5 May 2008 05:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.254 X-Spam-Level: X-Spam-Status: No, score=-53.254 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdkCbpr-PPUe; Mon, 5 May 2008 05:29:22 -0700 (PDT) Received: from 84.123.134.65.dyn.user.ono.com (84.123.134.65.dyn.user.ono.com [84.123.134.65]) by core3.amsl.com (Postfix) with SMTP id B41503A6B65; Mon, 5 May 2008 05:29:15 -0700 (PDT) X-Originating-IP: 66.115.155.234 by smtp.84.123.134.65; Mon, 05 May 2008 08:29:21 -0500 Message-ID: From: "Jake Eddy" Reply-To: "Jake Eddy" To: call-home-bounces@ietf.org Subject: Save thousands... no one will know Date: Mon, 05 May 2008 08:29:21 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://rahypepasif65.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://rahypepasif65.blogspot.com/ From owner-ccamp@ops.ietf.org Mon May 5 15:51:57 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD1A3A68A5 for ; Mon, 5 May 2008 15:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ8j5NQiGDCP for ; Mon, 5 May 2008 15:51:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE5A628C389 for ; Mon, 5 May 2008 15:51:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt9R7-000JfZ-RG for ccamp-data@psg.com; Mon, 05 May 2008 22:45:33 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jt9Qc-000JcD-6y for ccamp@ops.ietf.org; Mon, 05 May 2008 22:45:18 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2AEC33A68A5; Mon, 5 May 2008 15:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080505224502.2AEC33A68A5@core3.amsl.com> Date: Mon, 5 May 2008 15:45:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Description of the RSVP-TE Graceful Restart Procedures Author(s) : D. Li Filename : draft-ietf-ccamp-gr-description-02.txt Pages : 17 Date : 2008-5-5 The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gr-description-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-5153926.I-D@ietf.org> --NextPart-- From dickeyprovaccinist4885601@yahoo.com Mon May 5 18:34:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EB83A6A1F; Mon, 5 May 2008 18:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.505 X-Spam-Level: X-Spam-Status: No, score=-87.505 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnRTUtB3e-zm; Mon, 5 May 2008 18:34:37 -0700 (PDT) Received: from host-70-45-145-59.onelinkpr.net (host-70-45-145-59.onelinkpr.net [70.45.145.59]) by core3.amsl.com (Postfix) with SMTP id CE06D3A6830; Mon, 5 May 2008 18:34:32 -0700 (PDT) X-Originating-IP: 138.220.198.77 by smtp.70.45.145.59; Mon, 05 May 2008 21:34:37 -0500 Message-ID: From: "Art Hilliard" Reply-To: "Art Hilliard" To: call-home-bounces@ietf.org Subject: Replicas will save you thousands Date: Mon, 05 May 2008 21:34:37 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://zaraxyzamak24.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://zaraxyzamak24.blogspot.com/ From owner-ccamp@ops.ietf.org Mon May 5 19:08:16 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5823A6CCA for ; Mon, 5 May 2008 19:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvsphR8oH2vD for ; Mon, 5 May 2008 19:08:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A72D73A68B7 for ; Mon, 5 May 2008 19:07:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtCTu-000Cf8-Ru for ccamp-data@psg.com; Tue, 06 May 2008 02:00:38 +0000 Received: from [61.144.161.7] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtCTR-000Cc2-Jh for ccamp@ops.ietf.org; Tue, 06 May 2008 02:00:24 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K0F005ULC87OS@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 06 May 2008 10:00:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K0F001NIC87ME@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 06 May 2008 10:00:07 +0800 (CST) Received: from l37133 ([10.70.77.61]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K0F00MWXC87KW@szxml04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 06 May 2008 10:00:07 +0800 (CST) Date: Tue, 06 May 2008 10:00:07 +0800 From: Dan Li Subject: Fw: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt To: ccamp Cc: "Bardalai, Snigdho" , Arun Satyanarayana , "Gao, Jianhua" Message-id: <074101c8af1c$e88cdd30$3d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/mixed; boundary="Boundary_(ID_b7CfSTLsUDbjz3btt4K27w)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_b7CfSTLsUDbjz3btt4K27w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear CCAMPers, We just updated the GR-Description draft, there is no technical change in this version. We added some text to clarify the procedures for multi nodes which are not neighbors restart scenario. Best regards, Dan ----- Original Message ----- From: To: Cc: Sent: Tuesday, May 06, 2008 6:45 AM Subject: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Description of the RSVP-TE Graceful Restart Procedures > Author(s) : D. Li > Filename : draft-ietf-ccamp-gr-description-02.txt > Pages : 17 > Date : 2008-5-5 > > The Hello message for the Resource Reservation Protocol (RSVP) has > been defined to establish and maintain basic signaling node > adjacencies for Label Switching Routers (LSRs) participating in a > Multiprotocol Label Switching (MPLS) traffic engineered (TE) > network. The Hello message has been extended for use in Generalized > MPLS (GMPLS) network for state recovery of control channel or nodal > faults. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > --Boundary_(ID_b7CfSTLsUDbjz3btt4K27w) Content-type: text/plain; name=draft-ietf-ccamp-gr-description-02.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-ccamp-gr-description-02.txt Content-Type: text/plain Content-ID: <2008-5-5153926.I-D@ietf.org> --Boundary_(ID_b7CfSTLsUDbjz3btt4K27w)-- From owner-ccamp@ops.ietf.org Tue May 6 14:07:43 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBA33A68B6 for ; Tue, 6 May 2008 14:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Yng7TnSHgKZ for ; Tue, 6 May 2008 14:07:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 061033A692E for ; Tue, 6 May 2008 14:07:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtUHk-00030B-UY for ccamp-data@psg.com; Tue, 06 May 2008 21:01:16 +0000 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtUHI-0002xG-0v for ccamp@ops.ietf.org; Tue, 06 May 2008 21:01:02 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-203.messagelabs.com!1210107635!18325055!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 30530 invoked from network); 6 May 2008 21:00:35 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 6 May 2008 21:00:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m46L0jG0002437 for ; Tue, 6 May 2008 17:00:45 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m46L0cJ5002385 for ; Tue, 6 May 2008 17:00:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AFBC.3C892B14" Subject: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Date: Tue, 6 May 2008 16:00:37 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF1112CF11@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Thread-Index: AcivvDwYh3PM2WbnQICkg9X3bgptaA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AFBC.3C892B14 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable CCAMP, =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.t xt =20 Please send your comments to the mailing list prior to EOB May 20. =20 Adrian and Deborah ------_=_NextPart_001_01C8AFBC.3C892B14 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
This is to=20 initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-descri= ption-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 20.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AFBC.3C892B14-- From owner-ccamp@ops.ietf.org Wed May 7 05:22:10 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4843A711A for ; Wed, 7 May 2008 05:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLs80+PWG5HE for ; Wed, 7 May 2008 05:22:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14F263A7156 for ; Wed, 7 May 2008 05:21:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtiTp-000KJd-My for ccamp-data@psg.com; Wed, 07 May 2008 12:10:41 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtiTD-000KCw-DB for ccamp@ops.ietf.org; Wed, 07 May 2008 12:10:20 +0000 X-IronPort-AV: E=Sophos;i="4.27,448,1204498800"; d="scan'208";a="8256514" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 May 2008 14:09:59 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m47C9v4D013584; Wed, 7 May 2008 14:09:57 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m47C9vdT003568; Wed, 7 May 2008 12:09:57 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 14:09:57 +0200 Received: from [144.254.167.253] ([144.254.167.253]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 14:09:56 +0200 Message-ID: <48219BF8.4060401@cisco.com> Date: Wed, 07 May 2008 14:09:28 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2008 12:09:57.0013 (UTC) FILETIME=[43FAD450:01C8B03B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1909; t=1210162197; x=1211026197; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20Poll=20for=20WG=20Adoption=20of=20Two=2 0WSON=20documents |Sender:=20; bh=FftzsA+9oUttzcQPP1TfRabbOOCrdyAQBoV3ZCedr7E=; b=CrPDgDDLmNGwiFdrUdt9NAhzo7u8KQzN79Ag7b1ZiuJQLJjJbSyCXjoKFy e0DEPwqpbzn8s5/v3Q0gF3fw7jjL6w5OUyNTEXMyV9JuNI5x0cNh4cT54J0C snb6Buaypw; Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, yes support both I have also few comments on Framework WSON - Section 3.3.1 How about using a more generic OXC model? Or may be having a two pictures, one with the current ROADM and one with an OXC (degree > 2)? For sure the simple ROADM it's the easier to understand but looks to me too specific. The text: "As the degree of the ROADM increases beyond two it can have properties of both a switch(OXC)and a multiplexer" To me looks like the figure 1 has already multiplexing capability correct? For example a wavelength entering in what you call an add port is multiplexed on a *line* (keeping same terminology of the document) port. A simple questions on the switching matrix: looks like add/drop ports and *line* ports are considered the same in the matrix, correct? - Section 4.1 About time frame classification: Dynamic, pseudo-static and static. While the text explains why an RWA would appreciate some temporal information a classification like "relatively short" or "moderately long" are a bit difficult to understand to me, Long or short are compared to what?. - Section 6 Security Does it worth a reference to http://tools.ietf.org/id/draft-fang-mpls-gmpls-security-framework-01.txt? - A small ed note: in reference section the [G.994.1] is within both normative and informative sub-sections... Cheers G BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah From owner-ccamp@ops.ietf.org Wed May 7 07:57:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A245E28C1A7 for ; Wed, 7 May 2008 07:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2SiQ7MrZ+TO for ; Wed, 7 May 2008 07:57:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AB3E3A69A8 for ; Wed, 7 May 2008 07:57:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtkyR-000FAY-Ex for ccamp-data@psg.com; Wed, 07 May 2008 14:50:27 +0000 Received: from [146.50.98.70] (helo=korteweg.uva.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jtkxz-000F5I-K6 for ccamp@ops.ietf.org; Wed, 07 May 2008 14:50:13 +0000 Received: from mbp-freek.science.uva.nl ([146.50.22.53]) by korteweg.uva.nl with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 16:49:55 +0200 Message-ID: <4821C193.9050806@science.uva.nl> Date: Wed, 07 May 2008 16:49:55 +0200 From: Freek Dijkstra Organization: Universiteit van Amsterdam User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Network modeling & NML group in the OGF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 May 2008 14:49:55.0903 (UTC) FILETIME=[9D5D34F0:01C8B051] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi folks, I've was recently pointed to the WSON list by a colleague, who is liaison of the Open Grid Forum (OGF) towards the IETF [1]. The list has no archive, so I may have missed a few topics, but after reading the discussion on the difference between OOO and OEO or on wavelength versus waveband switching, I think there is a need for an explicit multilayer model. The MLN/MRN work at least has a syntax, but I have not seen a formal model. I'll post this to the CCAMP list rather than the WSON list since it is a bit more general. I just finished my PhD thesis on multi-layer path finding. I'll briefly mention this work (I apologize for the shameless plug) and than mention was is currently done in the OGF. Let's see if there is some mutual interest. We created a model and syntax called Network Description Language (NDL) [2]. A major goal was to enable complex multi-layer path finding, with a technology independent algorithm. "Complex" because multi-layer path can in fact contain loops [3], which is not possible in single layer networks. The technology independence (no technology-specific code) means that not only the networks are described in an abstract model, but so are the different technologies. For example, the path finding "learns" about characteristics of WDM by reading a file describing the technology. That file contains the different adaptations, layers and label definition (in our WDM example file, the labels are floats: the wavelength in nm, and the spacings are described as different adaptations. Interestingly it is possible to use the same model to make another technology description of WDM, for example with or without a group mux sublayer). Of course the challenge was to force the different technologies in such a generic model. Tagged Ethernet in particular took some effort. One thing that worked very well was to distinguish between two different switching capabilities: one "switching" for forwarding traffic with the same "label" (e.g. wavelength switching without wavelength conversion or Ethernet VLANs) and for forwarding while allowing label changes (e.g. timeslots in TDM or wavelength conversion). Beside the model, we create a syntax. Instead, our syntax is based on semantic web [4] and RDF. What worked very well was that we could easily separate the different subtopics: topologies description, (technology) layers, capabilities (such as the ability or inability of a device to convert between labels), domain abstraction, physical properties, etc. What's more, we could easily combine this information with different information such as policy descriptions and pointers to reservation systems. We are in the process of combining network description with a description of 4K very high definition digital cinema display, media and storage) [5], so that a metascheduler not only can take network resources but also storage and visualization resources into account. In case you wonder how our model compares with GMPLS: Jeroen van der Ham, a fellow PhD student, just wrote an interface to convert between our description and OSPF-TE. This was done in collaboration with Max Gigapop, a research network that also developed DRAGON, a free GMPLS implementation [6]). Our work is developed and in limited use in a community of national research networks called the GLIF [7], which provides circuit-switched network connection for e-science applications around the globe. ("limited" since it is restricted to a single layer for now). As for the relation with GMPLS: our model is based on functional elements as described in ITU-T G.805 [8], combined with the label concept in GMPLS. That is generic and powerful enough to describe and find paths in WDM, TDM, Ethernet and fiber switch networks [9]. So much for our model and the shameless plug. The reason I mention all this is that we are of course not the only ones to create a syntax to describe networks. OSPF-TE is an obvious other one. There are quite a few research projects which also create their own syntax. Some use GMPLS, though most that involve multi-layer networks create their own model and syntax. About a year ago, some of these groups joined forces to standardize on a network description. The Open Grid Forum (OGF) [1], a standardization body originally active in standardization of Grid software, has a working group, called Network Markup Language (NML), which does exactly such multi-layer network modelling [10]. Active members are us, developers of the PerfSONAR measurement software, and miscellaneous partners in GÉANT (European research network) projects. Each of these active members brings their own multi-layer models, each with each strengths and weaknesses. Clearly there is some overlap with CCAMP here. Of course, there are difference as well. The NML working groups mostly is concerned with multi-domain descriptions, and the interactions needed there. Thus, the ability to describe an abstracted view of the network, with capability information, pointers to services for policy decision and policy enforcement points, etc. Typical projects I see are research projects that provide dedicated network connections (either using Ethernet, DWDM, or TDM) through a collaboration of 5-20 network domains, each using their own inter-domain control plane software. Typical control planes I see are DRAGON, UCLP, G-Lambda, DRAC, AutoBAHN, etc. If you are interested, I gladly elaborate on either our model, the path finding, or the working group. Perhaps it would be could that we can share some of our use cases, requirements and solutions, while you some of the active members here could provide the NML working group with input from the CCAMP group. With kind regards, Freek Dijkstra [1] OGF http://www.ogf.org/ [2] Network Description Language, http://www.science.uva.nl/research/sne/ndl/ [3] Loop example in multi layer networks http://staff.science.uva.nl/~fdijkstr/presentations/Going-in-Loops.pdf (poster) or http://staff.science.uva.nl/~fdijkstr/publications/ndl-pathfinding.pdf (short article) [4] Semantic web, http://www.w3.org/2001/sw/ [5] 4k digital cinema, http://www.cinegrid.org/ [6] DRAGON, http://dragon.maxgigapop.net/ [7] GLIF community, http://www.glif.is/ [8] ITU-T G.805, http://www.itu.int/rec/T-REC-G.805/ [9] Technology descriptions in NDL, http://www.science.uva.nl/research/sne/ndl/?c=01-Schemas [10] NML-WG, https://forge.gridforum.org/sf/projects/nml-wg https://forge.gridforum.org/sf/projects/nml-wg From owner-ccamp@ops.ietf.org Wed May 7 09:35:27 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98FDC28C6CB for ; Wed, 7 May 2008 09:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjYAbaqgVsCX for ; Wed, 7 May 2008 09:35:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6883728C717 for ; Wed, 7 May 2008 09:30:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtmQf-0001RB-JK for ccamp-data@psg.com; Wed, 07 May 2008 16:23:41 +0000 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtmQC-0001NH-0A for ccamp@ops.ietf.org; Wed, 07 May 2008 16:23:26 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id m47GMutc051823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 09:22:57 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4821D76A.1000805@grotto-networking.com> Date: Wed, 07 May 2008 09:23:06 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Giovanni Martinelli CC: "BRUNGARD, DEBORAH A, ATTLABS" , ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> <48219BF8.4060401@cisco.com> In-Reply-To: <48219BF8.4060401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk Thanks for the good comments Giovanni, we'll incorporate them into the next revision. Also see below. Greg B. Giovanni Martinelli wrote: > Hi, > > yes support both > > I have also few comments on Framework WSON > > - Section 3.3.1 > How about using a more generic OXC model? Or may be having a two > pictures, one with the current ROADM and one with an OXC (degree > > 2)? For sure the simple ROADM it's the easier to understand but looks > to me too specific. --> We've (authors of the WSON info model draft) have been discussing these issues lately. So we'll be sure to make this more generic in at least one of the drafts (if not both). > > > The text: "As the degree of the ROADM increases beyond two it can have > properties of both a switch(OXC)and a multiplexer" > To me looks like the figure 1 has already multiplexing capability > correct? For example a wavelength entering in what you call an add > port is multiplexed on a *line* (keeping same terminology of the > document) port. > > A simple questions on the switching matrix: looks like add/drop ports > and *line* ports are considered the same in the matrix, correct? --> Yes. The difference between port types is given by the per port wavelength constraints. We are currently trying to make this a bit more rigorous. > > - Section 4.1 > About time frame classification: Dynamic, pseudo-static and static. > While the text explains why an RWA would appreciate some temporal > information a classification like "relatively short" or "moderately > long" are a bit difficult to understand to me, Long or short are > compared to what?. --> We'll fix this and/or remove it. Others share you concerns including the WG chairs. > > - Section 6 Security > Does it worth a reference to > http://tools.ietf.org/id/draft-fang-mpls-gmpls-security-framework-01.txt? --> Yes. > > - A small ed note: in reference section the [G.994.1] is within both > normative and informative sub-sections... --> All my fault. Will Fix. > > Cheers > G > > > > > > > BRUNGARD, DEBORAH A, ATTLABS wrote: >> CCAMP, >> >> From Philadelphia, we had good support for adoption of two of the >> WSON documents as CCAMP working group documents: >> >> - Framework for WSON >> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt >> >> >> - Lambda Labels >> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt >> >> >> Please express your opinions (authors, we welcome your opinion also). >> >> Thanks, >> Adrian and Deborah > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From owner-ccamp@ops.ietf.org Wed May 7 11:50:16 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5473A6908 for ; Wed, 7 May 2008 11:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1pVgY3fGRMX for ; Wed, 7 May 2008 11:50:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 425F23A6781 for ; Wed, 7 May 2008 11:50:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jtocf-000Ipn-EU for ccamp-data@psg.com; Wed, 07 May 2008 18:44:13 +0000 Received: from [146.50.98.70] (helo=korteweg.uva.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JtocU-000IoK-6C for ccamp@ops.ietf.org; Wed, 07 May 2008 18:44:07 +0000 Received: from mbp-freek.science.uva.nl ([145.99.148.34]) by korteweg.uva.nl with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 20:44:00 +0200 Message-ID: <4821F870.8050105@science.uva.nl> Date: Wed, 07 May 2008 20:44:00 +0200 From: Freek Dijkstra Organization: Universiteit van Amsterdam User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Network modeling & NML group in the OGF References: <4821C193.9050806@science.uva.nl> In-Reply-To: <4821C193.9050806@science.uva.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2008 18:44:00.0963 (UTC) FILETIME=[50DF4930:01C8B072] Sender: owner-ccamp@ops.ietf.org Precedence: bulk I got some off-list replies. Let me elaborate a bit. The network markup language (NML) working group in the OGF -in my view- seems focussed on network descriptions for multi-domain scenarios. In those scenarios loose coupling and extensions to refer to other resources are important. GMPLS seems mostly focussed on a control plane within a single administrative domain. Nevertheless, I see overlap. I imagine a future where GMPLS is used within a single administrative domain, that data is extracted and in abstracted form announced to select partners for multi-domain lightpath provisioning. Such a tool would be a lot easier if there was a common network model. Translating between two syntaxes is easy. Translating between two models is very hard. In an ideal world, every technology uses the same model, so conversion is easy. We don't live in an ideal world. For example, GMPLS does NOT follow G.805 and G.8080. To give two examples: Fundamental concepts in GMPLS are labels and capacity (bandwidth). Neither of these concept is is present in G.805. In GMPLS, there is no 1:1 relation between encapsulation "layers" and switching capability "layers". In GMPLS, there is (link connections and subnetwork connections are on the same layer network). Because of this difference in model, it is hard to convert from a set of TLV in OSPF-TE and a network description in G.805 functional elements or vice versa. What I would hope for the NML working group is to learn as much as possible from all these different models, and decide on one which is most usable for all, and is easy to convert to other models and syntaxes. Clearly, G.805 and G.8080 are input, but they are not complete (*). The model (if any) used in GMPLS is another input, and I am seeking that input from this list. Regards, Freek (*) For example, we like to add time-based information to track changes in the network topology. We like the label and switching capability concepts in GMPLs, neither of which is in G.805 or G.8080. Also you don't want to know how many people assume that a device interface maps to a single G.805 "connection point" -- that is not true, since a device interface is a physical interface, which may map to multiple logical interfaces, one for each layer. These things need to be specified. PS: It was perhaps not completely clear in my previous mail. We (the developers of the network description language, NDL) use RDF. However that this is not always true for everyone in the Network markup language (NML) working group in the OGF. Most of the other partners prefer to use XML for example. We decided to simply come up with a common model in UML, and allow multiple syntaxes. Again, if there is a common model, translating between syntaxes is trivial. That common model is the hard part. From kcohen2@att.com Thu May 8 11:49:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6873A6780 for ; Thu, 8 May 2008 11:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.22 X-Spam-Level: X-Spam-Status: No, score=-53.22 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_GET_MEDS=2.75, JM_REACTOR_MAILER=1, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_PH_SURBL=1.787, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0GsTzRIWaqf for ; Thu, 8 May 2008 11:49:34 -0700 (PDT) Received: from 150-31.dedicado.com.uy (150-31.dedicado.com.uy [201.221.31.150]) by core3.amsl.com (Postfix) with ESMTP id 718653A69AB for ; Thu, 8 May 2008 11:49:33 -0700 (PDT) Message-ID: <000701c8b13c$0212512d$be638898@weeahj> From: "vigara cialsi " To: Subject: 80% off for ccamp-archive Date: Thu, 08 May 2008 17:02:11 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Hello, make a right choice, get your meds from the most reliable online store. http://www.google.com/pagead/iclk?sa=l&ai=Hdfcxx&num=15098&adurl=http://ricekorea.co.kr/redir.html Coupon #nSG3 gerick prince From owner-ccamp@ops.ietf.org Thu May 8 17:10:01 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462A23A6EA9 for ; Thu, 8 May 2008 17:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFWU3mmSeF3W for ; Thu, 8 May 2008 17:10:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C2033A6E4D for ; Thu, 8 May 2008 17:10:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuG3q-000FRC-BC for ccamp-data@psg.com; Fri, 09 May 2008 00:02:06 +0000 Received: from [129.60.39.147] (helo=tama50.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuG3G-000FMM-OU for ccamp@ops.ietf.org; Fri, 09 May 2008 00:01:44 +0000 Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m4901RQv015267; Fri, 9 May 2008 09:01:27 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B8E5063EE; Fri, 9 May 2008 09:01:27 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B442263ED; Fri, 9 May 2008 09:01:27 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m4901RnH011212; Fri, 9 May 2008 09:01:27 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m4901QfD011203; Fri, 9 May 2008 09:01:26 +0900 (JST) Received: from [127.0.0.1] (neba-hp-shiomoto.nslab.ecl.ntt.co.jp [129.60.80.23]) by imc.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m4901MQc003044; Fri, 9 May 2008 09:01:26 +0900 (JST) Message-ID: <482393EA.4090404@lab.ntt.co.jp> Date: Fri, 09 May 2008 08:59:38 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk I support both. Those are important docs. Sorry for being late. Kohei > CCAMP, > > From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah -- Kohei Shiomoto, Ph.D NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 3787 Free online contents of "NTT Technical Review" available at https://www.ntt-review.jp/ From owner-ccamp@ops.ietf.org Fri May 9 04:05:16 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194FA3A6872 for ; Fri, 9 May 2008 04:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI98vMkGK6YB for ; Fri, 9 May 2008 04:05:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E6A43A6863 for ; Fri, 9 May 2008 04:05:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuQHz-000Ntt-DS for ccamp-data@psg.com; Fri, 09 May 2008 10:57:23 +0000 Received: from [80.86.78.228] (helo=fw.testbed.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuQHo-000NsT-Ci for ccamp@ops.ietf.org; Fri, 09 May 2008 10:57:18 +0000 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JuQGU-0002TJ-Bs for ccamp@ops.ietf.org; Fri, 09 May 2008 12:55:50 +0200 Received: from pat.acreo.se ([217.151.195.214]:58694 helo=[10.4.144.171]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JuQGR-0002T8-Iu; Fri, 09 May 2008 12:55:47 +0200 Message-ID: <48242DED.5090403@pi.nu> Date: Fri, 09 May 2008 12:56:45 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ccamp , mpls@ietf.org, pwe3 Subject: proposed charter update for the MPLS TP work Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk MPLS, CCAMP and PWE3 working groups, The Joint Working Team of the IETF and ITU-T has resulted in the agreement to create a Transport Profile for MPLS (MPLS TP). This effort requires the MPLS, PWE3 and CCAMP Working Groups are chartered to do the required work. The MPLS, PWE3 and CCAMP chairs proposes that we add the following paragraph to the three working group charters: "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs necessary to fulfill an MPLS Transport Profile (MPLS TP), the work on the MPLS TP needs to be coordinated between the three working groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP work." Please send your comments to the working group(s) mailing list(s) eob Friday May 16. Adrian, Deborah, Danny, Stewart, George and Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu From owner-ccamp@ops.ietf.org Fri May 9 09:03:09 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F76B3A68CC for ; Fri, 9 May 2008 09:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjrPO4mFOLQg for ; Fri, 9 May 2008 09:03:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D77C33A68B0 for ; Fri, 9 May 2008 09:03:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuUuo-00033L-Tn for ccamp-data@psg.com; Fri, 09 May 2008 15:53:46 +0000 Received: from [217.115.75.233] (helo=demumfd001.nsn-inter.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuUud-00031O-No for ccamp@ops.ietf.org; Fri, 09 May 2008 15:53:41 +0000 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m49FrS6e020157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2008 17:53:28 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m49FrSae029423; Fri, 9 May 2008 17:53:28 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 17:53:28 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: proposed charter update for the MPLS TP work Date: Fri, 9 May 2008 17:53:19 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83D0EEED@DEMUEXC014.nsn-intra.net> In-Reply-To: <48242DED.5090403@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proposed charter update for the MPLS TP work Thread-Index: AcixxZ/4OD/celZWRyO83Uds8ojh7AAJxiSg From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Loa Andersson" , "ccamp" , , "pwe3" X-OriginalArrivalTime: 09 May 2008 15:53:28.0111 (UTC) FILETIME=[D2717BF0:01C8B1EC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk I support the extension in the charters of the three WGs.=20 Best regards, Nurit -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Loa Andersson Sent: Friday, May 09, 2008 13:57 To: ccamp; mpls@ietf.org; pwe3 Subject: proposed charter update for the MPLS TP work MPLS, CCAMP and PWE3 working groups, The Joint Working Team of the IETF and ITU-T has resulted in the agreement to create a Transport Profile for MPLS (MPLS TP). This effort requires the MPLS, PWE3 and CCAMP Working Groups are chartered to do the required work. The MPLS, PWE3 and CCAMP chairs proposes that we add the following paragraph to the three working group charters: "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs necessary to fulfill an MPLS Transport Profile (MPLS TP), the work on the MPLS TP needs to be coordinated between the three working groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP work." Please send your comments to the working group(s) mailing list(s) eob Friday May 16. Adrian, Deborah, Danny, Stewart, George and Loa --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu From owner-ccamp@ops.ietf.org Fri May 9 14:30:53 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9442E3A67D0 for ; Fri, 9 May 2008 14:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kulxnaSh4hsc for ; Fri, 9 May 2008 14:30:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACFA73A67A8 for ; Fri, 9 May 2008 14:30:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jua2C-000Gz6-OR for ccamp-data@psg.com; Fri, 09 May 2008 21:21:44 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jua1m-000GwV-JN for ccamp@ops.ietf.org; Fri, 09 May 2008 21:21:31 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 May 2008 14:21:17 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m49LLHB5002838; Fri, 9 May 2008 14:21:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m49LKVai017212; Fri, 9 May 2008 21:21:17 GMT Received: from xmb-rtp-206.amer.cisco.com ([64.102.31.32]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 17:21:13 -0400 Received: from 10.98.32.163 ([10.98.32.163]) by xmb-rtp-206.amer.cisco.com ([64.102.31.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 May 2008 21:21:13 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 May 2008 17:21:12 -0400 Subject: Re: [mpls] proposed charter update for the MPLS TP work From: George Swallow To: Shahram Davari , "'Loa Andersson'" , "'ccamp'" , , "'pwe3'" Message-ID: Thread-Topic: [mpls] proposed charter update for the MPLS TP work Thread-Index: Acix47OpiyIUe70hTtS1Q5bd3k6JiAAH18bgAAPf2YAAAgI4Sw== In-Reply-To: <003f01c8b212$fdb59370$f920ba50$@org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 May 2008 21:21:13.0641 (UTC) FILETIME=[9C033990:01C8B21A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2098; t=1210368077; x=1211232077; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:=20George=20Swallow=20 |Subject:=20Re=3A=20[mpls]=20proposed=20charter=20update=20 for=20the=20MPLS=20TP=20work |Sender:=20; bh=Z0OwBvOHgMQQEANh9cC2DSv++1a53eNHp7nczcxbviQ=; b=a1sbWnVIamWVsl7XMEmrT4cbZEGDkLmFvOPGfm9+Sf0w8Bns/j/Ng8mJuV y+QhiO7Aj83XdT6r4QC4bCfB2P1FdzDP7TOK7eQwhTpRE+wmNqAeyk6RKQNN +lnfSPOjVD; Authentication-Results: sj-dkim-2; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk We are not reducing anything in the MPLS architecture and protocols. There will be a few extension. The Transport Profile will define a profile of the MPLS architecture and that is were the reduction comes. ...George On 5/9/08 4:26 PM, "Shahram Davari" wrote: > Hi Loa, > > Just a clarification. The term reduction means components of the MPLS > architecture left unused. > > Regards, > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: May-09-08 2:52 PM > To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' > Subject: Re: [mpls] proposed charter update for the MPLS TP work > > Hi Loa, > > The term "extension" is not very appropriate. It doesn't cover the possible > case of MPLS TP requiring a reduction in MPLS functionality? > > How about changing that to "extensions and reductions" > > Regards, > -Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: May-09-08 6:57 AM > To: ccamp; mpls@ietf.org; pwe3 > Subject: [mpls] proposed charter update for the MPLS TP work > > MPLS, CCAMP and PWE3 working groups, > > > The Joint Working Team of the IETF and ITU-T has resulted in > the agreement to create a Transport Profile for MPLS (MPLS TP). > This effort requires the MPLS, PWE3 and CCAMP Working Groups > are chartered to do the required work. > > The MPLS, PWE3 and CCAMP chairs proposes that we add the > following paragraph to the three working group charters: > > "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs > necessary to fulfill an MPLS Transport Profile (MPLS TP), the work > on the MPLS TP needs to be coordinated between the three working > groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP > work." > > Please send your comments to the working group(s) mailing list(s) > eob Friday May 16. > > Adrian, Deborah, Danny, Stewart, George and Loa > From owner-ccamp@ops.ietf.org Fri May 9 14:44:17 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92E13A67D0 for ; Fri, 9 May 2008 14:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0tf8CVhjb13 for ; Fri, 9 May 2008 14:44:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DEDF3A67A8 for ; Fri, 9 May 2008 14:44:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuaFt-000IHF-La for ccamp-data@psg.com; Fri, 09 May 2008 21:35:53 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuaFO-000IE7-Rq for ccamp@ops.ietf.org; Fri, 09 May 2008 21:35:39 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m49LVUVR011738; Fri, 9 May 2008 22:31:30 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m49LVQZe011730; Fri, 9 May 2008 22:31:28 +0100 Message-ID: <02b601c8b21c$027f3a60$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Shahram Davari" Cc: "'ccamp'" , , "'pwe3'" References: <48242DED.5090403@pi.nu> <003d01c8b205$c048b470$40da1d50$@org><003f01c8b212$fdb59370$f920ba50$@org> <4824B981.7020803@cisco.com> Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work Date: Fri, 9 May 2008 22:31:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Perhaps... OLD Include extensions to the [MPLS, PWE3, CCAMP] protocols NEW Include modifications and extensions to the [MPLS, PWE3, CCAMP] protocols and procedures Adrian ----- Original Message ----- From: "Stewart Bryant" To: "Shahram Davari" Cc: "'ccamp'" ; ; "'pwe3'" Sent: Friday, May 09, 2008 9:52 PM Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work >I think it was fine as it was. We are not going to do and unnecessary > extensions, and we are not going to remove any functionality that is > already in there because we need it for other applications. > > We could perhaps say: > > "Include necessary extensions ...." to make it completely clear. > > Stewart > > Shahram Davari wrote: >> Hi Loa, >> >> Just a clarification. The term reduction means components of the MPLS >> architecture left unused. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Shahram Davari >> Sent: May-09-08 2:52 PM >> To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' >> Subject: Re: [mpls] proposed charter update for the MPLS TP work >> >> Hi Loa, >> >> The term "extension" is not very appropriate. It doesn't cover the >> possible >> case of MPLS TP requiring a reduction in MPLS functionality? >> >> How about changing that to "extensions and reductions" >> >> Regards, >> -Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Loa >> Andersson >> Sent: May-09-08 6:57 AM >> To: ccamp; mpls@ietf.org; pwe3 >> Subject: [mpls] proposed charter update for the MPLS TP work >> >> MPLS, CCAMP and PWE3 working groups, >> >> >> The Joint Working Team of the IETF and ITU-T has resulted in >> the agreement to create a Transport Profile for MPLS (MPLS TP). >> This effort requires the MPLS, PWE3 and CCAMP Working Groups >> are chartered to do the required work. >> >> The MPLS, PWE3 and CCAMP chairs proposes that we add the >> following paragraph to the three working group charters: >> >> "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs >> necessary to fulfill an MPLS Transport Profile (MPLS TP), the work >> on the MPLS TP needs to be coordinated between the three working >> groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP >> work." >> >> Please send your comments to the working group(s) mailing list(s) >> eob Friday May 16. >> >> Adrian, Deborah, Danny, Stewart, George and Loa >> >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From owner-ccamp@ops.ietf.org Mon May 12 02:01:37 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1DA3A6895 for ; Mon, 12 May 2008 02:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0JUlnIgzTxq for ; Mon, 12 May 2008 02:01:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 796123A67AA for ; Mon, 12 May 2008 02:01:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvSYQ-0001D8-A0 for ccamp-data@psg.com; Mon, 12 May 2008 07:34:38 +0000 Received: from [80.86.78.228] (helo=fw.testbed.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvSXw-00019c-RW for ccamp@ops.ietf.org; Mon, 12 May 2008 07:34:23 +0000 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JvSWL-0001Fr-4n for ccamp@ops.ietf.org; Mon, 12 May 2008 09:32:29 +0200 Received: from pat.acreo.se ([217.151.195.214]:1253 helo=[10.4.144.171]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JvSWK-0001FZ-6I; Mon, 12 May 2008 09:32:28 +0200 Message-ID: <4827F2D3.7030609@pi.nu> Date: Mon, 12 May 2008 09:33:39 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adrian Farrel CC: stbryant@cisco.com, Shahram Davari , 'ccamp' , mpls@ietf.org, 'pwe3' Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work References: <48242DED.5090403@pi.nu> <003d01c8b205$c048b470$40da1d50$@org><003f01c8b212$fdb59370$f920ba50$@org> <4824B981.7020803@cisco.com> <02b601c8b21c$027f3a60$0200a8c0@your029b8cecfe> In-Reply-To: <02b601c8b21c$027f3a60$0200a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk All, Adrian Farrel wrote: > Hi, > > Perhaps... > OLD > Include extensions to the [MPLS, PWE3, CCAMP] protocols > NEW > Include modifications and extensions to the [MPLS, PWE3, CCAMP] > protocols and procedures my take on this that we are talking about "extensions" relative the the existing specification, it is quite possible for an extension to leave "components of the MPLS architecture unused", that is in fact the case with most of our documents. Consequently I agree with Stewart, and would oppose words like, reduce and modify, since that implies that we intend to *change* the MPLS architecture, while one of the foundations of the agreement to create an MPLS TP was that it should fit into the MPLS architecture. /Loa > > Adrian > > ----- Original Message ----- From: "Stewart Bryant" > To: "Shahram Davari" > Cc: "'ccamp'" ; ; "'pwe3'" > > Sent: Friday, May 09, 2008 9:52 PM > Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work > > >> I think it was fine as it was. We are not going to do and unnecessary >> extensions, and we are not going to remove any functionality that is >> already in there because we need it for other applications. >> >> We could perhaps say: >> >> "Include necessary extensions ...." to make it completely clear. >> >> Stewart >> >> Shahram Davari wrote: >>> Hi Loa, >>> >>> Just a clarification. The term reduction means components of the MPLS >>> architecture left unused. >>> >>> Regards, >>> Shahram >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Shahram Davari >>> Sent: May-09-08 2:52 PM >>> To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' >>> Subject: Re: [mpls] proposed charter update for the MPLS TP work >>> >>> Hi Loa, >>> >>> The term "extension" is not very appropriate. It doesn't cover the >>> possible >>> case of MPLS TP requiring a reduction in MPLS functionality? >>> >>> How about changing that to "extensions and reductions" >>> >>> Regards, >>> -Shahram >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of Loa >>> Andersson >>> Sent: May-09-08 6:57 AM >>> To: ccamp; mpls@ietf.org; pwe3 >>> Subject: [mpls] proposed charter update for the MPLS TP work >>> >>> MPLS, CCAMP and PWE3 working groups, >>> >>> >>> The Joint Working Team of the IETF and ITU-T has resulted in >>> the agreement to create a Transport Profile for MPLS (MPLS TP). >>> This effort requires the MPLS, PWE3 and CCAMP Working Groups >>> are chartered to do the required work. >>> >>> The MPLS, PWE3 and CCAMP chairs proposes that we add the >>> following paragraph to the three working group charters: >>> >>> "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs >>> necessary to fulfill an MPLS Transport Profile (MPLS TP), the work >>> on the MPLS TP needs to be coordinated between the three working >>> groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP >>> work." >>> >>> Please send your comments to the working group(s) mailing list(s) >>> eob Friday May 16. >>> >>> Adrian, Deborah, Danny, Stewart, George and Loa >>> >>> >>> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu From owner-ccamp@ops.ietf.org Mon May 12 05:15:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F4C28C269 for ; Mon, 12 May 2008 05:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3xnpdATV7lw for ; Mon, 12 May 2008 05:15:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D953F28C1C1 for ; Mon, 12 May 2008 05:15:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvWet-0003k8-MC for ccamp-data@psg.com; Mon, 12 May 2008 11:57:35 +0000 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvWeO-0003fk-AB for ccamp@ops.ietf.org; Mon, 12 May 2008 11:57:20 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 12:56:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] [mpls] proposed charter update for the MPLS TP work Date: Mon, 12 May 2008 12:55:50 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C02653B26@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <4827F2D3.7030609@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] [mpls] proposed charter update for the MPLS TP work Thread-Index: Aci0AvvVV4jxuwRrSG6pvaXj9JFLbwAI4tuQ From: To: , , Cc: , , , X-OriginalArrivalTime: 12 May 2008 11:56:49.0284 (UTC) FILETIME=[4285AC40:01C8B427] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Loa/Adrian/Stewart, I think it would be really useful if someone could summarise what specific proposals/options are being considered for MPLS-TP. In particular, given: - most operators would regard an OOB CP as an essential component of a transport network (and this is a forced requirement in the co-cs mode anyway); - GMPLS already uses an OOB CP and there is a long-standing CCAMPs charter item to unify the GMPLS/MPLS CPs; - I believe re-using common CP techniques would also be of interest to many operators; then it would appear that the MPLS-TP initiative provides a very good opportunity to address this. Any comments? regards, Neil=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Loa Andersson > Sent: 12 May 2008 08:34 > To: Adrian Farrel > Cc: stbryant@cisco.com; Shahram Davari; 'ccamp'; mpls@ietf.org; 'pwe3' > Subject: Re: [PWE3] [mpls] proposed charter update for the=20 > MPLS TP work >=20 >=20 > All, >=20 >=20 >=20 > Adrian Farrel wrote: > > Hi, > >=20 > > Perhaps... > > OLD > > Include extensions to the [MPLS, PWE3, CCAMP] protocols > > NEW > > Include modifications and extensions to the [MPLS, PWE3, CCAMP] > > protocols and procedures >=20 > my take on this that we are talking about "extensions"=20 > relative the the existing specification, it is quite possible=20 > for an extension to leave "components of the MPLS=20 > architecture unused", that is in fact the case with most of=20 > our documents. >=20 > Consequently I agree with Stewart, and would oppose words=20 > like, reduce and modify, since that implies that we intend to=20 > *change* the MPLS architecture, while one of the foundations=20 > of the agreement to create an MPLS TP was that it should fit=20 > into the MPLS architecture. >=20 > /Loa > >=20 > > Adrian > >=20 > > ----- Original Message ----- From: "Stewart Bryant"=20 > > > > To: "Shahram Davari" > > Cc: "'ccamp'" ; ; "'pwe3'"=20 > > > > Sent: Friday, May 09, 2008 9:52 PM > > Subject: Re: [PWE3] [mpls] proposed charter update for the=20 > MPLS TP work > >=20 > >=20 > >> I think it was fine as it was. We are not going to do and=20 > unnecessary=20 > >> extensions, and we are not going to remove any=20 > functionality that is=20 > >> already in there because we need it for other applications. > >> > >> We could perhaps say: > >> > >> "Include necessary extensions ...." to make it completely clear. > >> > >> Stewart > >> > >> Shahram Davari wrote: > >>> Hi Loa, > >>> > >>> Just a clarification. The term reduction means components of the=20 > >>> MPLS architecture left unused. > >>> > >>> Regards, > >>> Shahram > >>> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org=20 > [mailto:mpls-bounces@ietf.org] On Behalf=20 > >>> Of Shahram Davari > >>> Sent: May-09-08 2:52 PM > >>> To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' > >>> Subject: Re: [mpls] proposed charter update for the MPLS TP work > >>> > >>> Hi Loa, > >>> > >>> The term "extension" is not very appropriate. It doesn't cover the > >>> possible > >>> case of MPLS TP requiring a reduction in MPLS functionality? > >>> > >>> How about changing that to "extensions and reductions" > >>> > >>> Regards, > >>> -Shahram > >>> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org=20 > [mailto:mpls-bounces@ietf.org] On Behalf > >>> Of Loa > >>> Andersson > >>> Sent: May-09-08 6:57 AM > >>> To: ccamp; mpls@ietf.org; pwe3 > >>> Subject: [mpls] proposed charter update for the MPLS TP work > >>> > >>> MPLS, CCAMP and PWE3 working groups, > >>> > >>> > >>> The Joint Working Team of the IETF and ITU-T has resulted in the=20 > >>> agreement to create a Transport Profile for MPLS (MPLS TP). This=20 > >>> effort requires the MPLS, PWE3 and CCAMP Working Groups are=20 > >>> chartered to do the required work. > >>> > >>> The MPLS, PWE3 and CCAMP chairs proposes that we add the=20 > following=20 > >>> paragraph to the three working group charters: > >>> > >>> "- Include extensions to the [MPLS, PWE3, CCAMP]=20 > protocols and RFCs > >>> necessary to fulfill an MPLS Transport Profile=20 > (MPLS TP), the work > >>> on the MPLS TP needs to be coordinated between the=20 > three working > >>> groups (MPLS, PWE3 and CCAMP) that are chartered to=20 > do MPLS TP > >>> work." > >>> > >>> Please send your comments to the working group(s) mailing list(s)=20 > >>> eob Friday May 16. > >>> > >>> Adrian, Deborah, Danny, Stewart, George and Loa > >>> > >>> > >>> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > >> > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.nu >=20 >=20 From owner-ccamp@ops.ietf.org Mon May 12 08:42:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4013A69A7 for ; Mon, 12 May 2008 08:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.381 X-Spam-Level: X-Spam-Status: No, score=-104.381 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er6cQZArF0HZ for ; Mon, 12 May 2008 08:42:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0DE73A67B3 for ; Mon, 12 May 2008 08:42:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jva47-0004sO-DW for ccamp-data@psg.com; Mon, 12 May 2008 15:35:51 +0000 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jva3c-0004o3-OY for ccamp@ops.ietf.org; Mon, 12 May 2008 15:35:36 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-12.tower-203.messagelabs.com!1210606510!19484975!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 13307 invoked from network); 12 May 2008 15:35:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 12 May 2008 15:35:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4CFZIcA032233 for ; Mon, 12 May 2008 11:35:18 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4CFZ7IT032095 for ; Mon, 12 May 2008 11:35:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B445.C1A5574B" Subject: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02 Date: Mon, 12 May 2008 10:35:06 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF111C79A8@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10F7A8D2@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02 Thread-Index: AcinAma4cVOgNqu6REeXIW68/i9pSwNQpY7A References: <449B2580D802A443A923DABF3EAB82AF10F7A8D2@OCCLUST04EVS1.ugd.att.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B445.C1A5574B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 We completed the last call on draft-ietf-ccamp-pc-and-sc-reqs-02 with no comments/no updates needed. =20 I'll do the document shepherding. =20 Thanks, Deborah ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Friday, April 25, 2008 2:30 PM To: ccamp@ops.ietf.org Subject: Working Group Last Call: draft-ietf-ccamp-pc-and-sc-reqs-02 WG, =20 To ensure you have weekend reading material (especially here in the NE with our yet another rainy weekend), we have two more documents which we discussed in Phila to Last Call. I'll send separate mails. =20 And don't forget the Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end tomorrow. =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.t xt =20 Please send your comments to the mailing list prior to EOB May 9. =20 Adrian and Deborah ------_=_NextPart_001_01C8B445.C1A5574B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
We completed the last call on=20 draft-ietf-ccamp-pc-and-sc-reqs-02 with no comments/no updates=20 needed.
 
I'll do the document = shepherding.
 
Thanks,
Deborah

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Friday, April 25, 2008 2:30 PM
To:=20 ccamp@ops.ietf.org
Subject: Working Group Last Call:=20 draft-ietf-ccamp-pc-and-sc-reqs-02

WG,
 
To = ensure you have=20 weekend reading material (especially here in the NE with our yet=20 another rainy weekend), we have two more documents which we = discussed in=20 Phila to Last Call. I'll send separate mails.
 
And = don't forget the=20 Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end=20 tomorrow.
 
This = is to initiate=20 a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc= -reqs-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 9.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8B445.C1A5574B-- From owner-ccamp@ops.ietf.org Mon May 12 08:58:25 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D9A3A6AEA for ; Mon, 12 May 2008 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.437 X-Spam-Level: X-Spam-Status: No, score=-104.437 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8rGe+0yKGPX for ; Mon, 12 May 2008 08:58:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DF203A6AF1 for ; Mon, 12 May 2008 08:58:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvaJ8-0006dC-GP for ccamp-data@psg.com; Mon, 12 May 2008 15:51:22 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvaIe-0006Ys-Iy for ccamp@ops.ietf.org; Mon, 12 May 2008 15:51:07 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1210607449!445067!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 10498 invoked from network); 12 May 2008 15:50:49 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 12 May 2008 15:50:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4CFonEh010311 for ; Mon, 12 May 2008 11:50:49 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4CFogff010231 for ; Mon, 12 May 2008 11:50:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B447.EE8157F4" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Mon, 12 May 2008 10:50:40 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF111C79E6@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAKN2veg References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B447.EE8157F4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 We have good support for both of these documents. =20 Authors, please submit your documents with the following titles: Framework (same title as now): Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) draft-ietf-ccamp-wavelength-switched-framework-00.txt =20 Labels (different title proposed): Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt =20 Thanks, Adrian and Deborah =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 11:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8B447.EE8157F4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
We have good support for both of these=20 documents.
 
Authors, please submit your documents with = the=20 following titles:
Framework (same title as = now):
Framework for GMPLS and PCE = Control of=20 Wavelength Switched Optical Networks (WSON)
draft-ietf-ccamp-wavelength-switched-framework-00.txt
 
Labels=20 (different title proposed):
Generalized Labels for G.694 = Lambda-Switching=20 Capable Label Switching Routers
draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt<= /DIV>
 
Thanks,
Adrian and Deborah
 

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, April 29, 2008 11:39 AM
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON=20 documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8B447.EE8157F4-- From owner-ccamp@ops.ietf.org Mon May 12 11:20:52 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4423A689E for ; Mon, 12 May 2008 11:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SyZZ36rLzy3 for ; Mon, 12 May 2008 11:20:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CF2B3A6882 for ; Mon, 12 May 2008 11:20:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvcYd-000Pwh-16 for ccamp-data@psg.com; Mon, 12 May 2008 18:15:31 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvcY8-000PsQ-Ul for ccamp@ops.ietf.org; Mon, 12 May 2008 18:15:15 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 325393A67EE; Mon, 12 May 2008 11:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512181502.325393A67EE@core3.amsl.com> Date: Mon, 12 May 2008 11:15:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro Filename : draft-ietf-ccamp-gmpls-mln-reqs-10.txt Pages : 26 Date : 2008-5-12 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12110542.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon May 12 17:24:34 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35D43A687E for ; Mon, 12 May 2008 17:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMAYuN4UjG5V for ; Mon, 12 May 2008 17:24:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C565E3A6767 for ; Mon, 12 May 2008 17:24:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JviBk-000Bny-Ch for ccamp-data@psg.com; Tue, 13 May 2008 00:16:16 +0000 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JviBA-000BlA-RT for ccamp@ops.ietf.org; Tue, 13 May 2008 00:15:55 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id B7745EC92E; Tue, 13 May 2008 09:15:39 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id E68E9EC923; Tue, 13 May 2008 09:15:36 +0900 (JST) Received: from [127.0.0.1] (dhcp195.wlan.kddilabs.jp [172.19.110.195]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 853EB578111; Tue, 13 May 2008 09:15:35 +0900 (JST) Message-ID: <4828DDA1.1020409@kddilabs.jp> Date: Tue, 13 May 2008 09:15:29 +0900 From: Tomohiro Otani User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" Cc: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> <449B2580D802A443A923DABF3EAB82AF111C79E6@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF111C79E6@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Deboraha, I will upload the revised document shortly. Regards, Tomo BRUNGARD, DEBORAH A, ATTLABS =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D= =E3=81=BE=E3=81=97=E3=81=9F: > Hi, > We have good support for both of these documents. > Authors, please submit your documents with the following titles: > Framework (same title as now): > Framework for GMPLS and PCE Control of Wavelength Switched Optical=20 > Networks (WSON) > draft-ietf-ccamp-wavelength-switched-framework-00.txt > Labels (different title proposed): > Generalized Labels for G.694 Lambda-Switching Capable Label Switching=20 > Routers > draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt > Thanks, > Adrian and Deborah > > -----------------------------------------------------------------------= - > *From:* owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] *On=20 > Behalf Of *BRUNGARD, DEBORAH A, ATTLABS > *Sent:* Tuesday, April 29, 2008 11:39 AM > *To:* ccamp@ops.ietf.org > *Subject:* Poll for WG Adoption of Two WSON documents > > CCAMP, > From Philadelphia, we had good support for adoption of two of the WSON=20 > documents as CCAMP working group documents: > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-sw= itched-03.txt > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labe= ls-02.txt > Please express your opinions (authors, we welcome your opinion also). > Thanks, > Adrian and Deborah From owner-ccamp@ops.ietf.org Tue May 13 01:11:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5593A6BDE for ; Tue, 13 May 2008 01:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.535 X-Spam-Level: X-Spam-Status: No, score=-5.535 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb+SqRh9XQvX for ; Tue, 13 May 2008 01:11:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85A173A6BDD for ; Tue, 13 May 2008 01:11:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvpUI-0007Ym-OS for ccamp-data@psg.com; Tue, 13 May 2008 08:03:54 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JvpTi-0007TG-Jl for ccamp@ops.ietf.org; Tue, 13 May 2008 08:03:33 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D65A20BA9; Tue, 13 May 2008 10:02:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7FE5420532; Tue, 13 May 2008 10:02:47 +0200 (CEST) Received: from eseldmw101.eemea.ericsson.se ([136.225.228.103]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 10:02:47 +0200 Received: from mail pickup service by eseldmw101.eemea.ericsson.se with Microsoft SMTPSVC; Tue, 13 May 2008 10:02:44 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by eseldmw101.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 09:37:52 +0200 Received: from mailgw1.ericsson.se ([193.180.251.45]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 20:15:36 +0200 Received: from mailgw1.ericsson.se (unknown [127.0.0.1]) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id 5730C58C005; Mon, 12 May 2008 20:15:36 +0200 (CEST) X-AuditID: c1b4fb3c-ad89abb00000193b-ea-48294b275769 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id D574C500007; Mon, 12 May 2008 20:15:35 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B77328C124; Mon, 12 May 2008 11:15:05 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 325393A67EE; Mon, 12 May 2008 11:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512181502.325393A67EE@core3.amsl.com> Date: Mon, 12 May 2008 11:15:02 -0700 (PDT) Cc: ccamp@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 12 May 2008 18:15:36.0454 (UTC) FILETIME=[2CF89A60:01C8B45C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro Filename : draft-ietf-ccamp-gmpls-mln-reqs-10.txt Pages : 26 Date : 2008-5-12 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12110542.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ccamp@ops.ietf.org Tue May 13 18:44:54 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DDB28C2E2 for ; Tue, 13 May 2008 18:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QsQnagE2G5d for ; Tue, 13 May 2008 18:44:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07F723A686D for ; Tue, 13 May 2008 18:44:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jw5wh-000McF-Pk for ccamp-data@psg.com; Wed, 14 May 2008 01:38:19 +0000 Received: from [202.32.8.206] (helo=tyo202.gate.nec.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jw5wF-000MZh-0X for ccamp@ops.ietf.org; Wed, 14 May 2008 01:38:06 +0000 Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m4E1bkOJ006702; Wed, 14 May 2008 10:37:46 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m4E1bk827753; Wed, 14 May 2008 10:37:46 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id m4E1bk3l013924; Wed, 14 May 2008 10:37:46 +0900 (JST) Received: from arakidsk ([10.56.131.136] [10.56.131.136]) by mail.jp.nec.com with ESMTP; Wed, 14 May 2008 10:37:45 +0900 From: "Soichiro Araki" To: , , , Cc: Subject: Call for PARTICIPATION - 4th InternationalConference on IP + Optical Network (iPOP 2008) Date: Wed, 14 May 2008 10:37:53 +0900 Organization: NEC Corp. Message-Id: <002d01c8b563$20945180$8883380a@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci0iuWQmOlMAus8TZGRvUr4IXtYTwA1s1jA Sender: owner-ccamp@ops.ietf.org Precedence: bulk +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [Our apologies if you receive multiple copies of this message] ***************************************************************** * CALL FOR PARTICIPATION * * * * Conference on IP + Optical Network (iPOP208) * * http://www.ipop2008.com/ * * * * June 5-6, 2008 Tokyo, Japan * * * * Participation fee: free * * * * Please register through * * http://www.pilab.jp/ipop2008/registration/index.html * ***************************************************************** ----------------------------------------------------------------------------- Technical Sessions ----------------------------------------------------------------------------- Day 1 (June 5, 2008) ----------------------------------------------------------------------------- Tech. Session 1: ASON Chair: Kireeti Kompella, Juniper, USA o "Control Plane Resilience and Security in GMPLS Networks : Fact and Fiction," Adrian Farrel (Old Dog Consulting, UK) o "e2e GMPLS P&R with next generation interface for the green networking," Hidetsugu Sugiyama (Juniper Networks, Japan) o "Automated End-to-end Circuit Provisioning for high bandwidth demand applications: the challenges and our experiences in 3TNet," Weiqiang Sun, Guowu Xie, Yaohui Jin, Wei Guo and Weisheng Hu (Shanghai Jiao Tong University, P. R. China) ----------------------------------------------------------------------------- Tech. Session 2: WSON Chair: Wataru Imajuku, NTT, Japan o "GMPLS Extensions in Support of All-optical Networking," Hongxiang Guo, Takehiro Tsuritani, Noboru Yoshikane, Tomohiro Otani (KDDI R&D, Japan) o "Optical Reach Computation with GMPLS," Snigdho Bardalai, Richard Colter, Sugiya Hideaki, Fred Gruman, Mike White, Sanjay Gera (Fujitsu, USA) o "GMPLS perspectives to control WSON," Pierre Peloso, Benoit RONOT, Martin VIGOUREUX, Richard DOUVILLE (Alcatel-Lucent, France) o "Wavelength Switched Optical Networks with Distributed Control," Hiroaki Harai and Sugang Xu (NICT, Japan) ----------------------------------------------------------------------------- Day 2 (June 6, 2008) ----------------------------------------------------------------------------- Tech. Session 3: PCE Chair: Young Lee, Huawei, USA o "Inter-Carrier PCE-Based Path Computation in Keihanna Interoperablity Project" Tomonori Takeda, Eiji Oki (NTT, Japan), Yohei Iizawa, Itaru Nishioka (NEC, Japan), Machiko Asaie, Kazuhiro Kusama (Hitachi, Japan), Shuichi Okamoto, and Tomohiro Otani (KDDI R&D, Japan) o "End-to-End path routing with PCEs in multi-domain GMPLS networks" Itaru Nishioka, Shinya Ishida, Yohei Iizawa (NEC, Japan) o "Path Computation Issues and Solutions in Wavelength Switched Optical Networks (WSON)" Young Lee (Huawei, USA), Greg Bernstein (Grotto Networks, USA), Daniel King (Aria-Networks, UK) o "Deploying Advanced Path Computation Technologies for Optical Transport Networks," Daniel King (Aria Networks, UK), Takehiro Tsuritani (KDDI R&D, Japan) ----------------------------------------------------------------------------- Tech. Session 4: GELS Chair: Don Fedyk, Nortel, USA o "Experimenting with GMPLS to control a PBB-TE network" Benoit Tremblay, Attila Takacs, Howard Green (Ericsson Research, Canada) o "Employing GMPLS control for PBB-TE networks" Don Fedyk (Nortel, USA) o "Example of a GMPLS control plane interconnected with an Ethernet data plane in a rack-mounted prototype" A. Dupas, R. Boislaigue, C. Cosse-maniere, G.Post, M. Lorret (Alcatel-lucent Bell-labs, France) ----------------------------------------------------------------------------- Tech. Session 5: OAM Chair: Adrian Farrel, Old Dog Consulting, UK o "Design, implementation and validation within ADRENALINER testbed of a Path Computation Element for Wavelength Switched Optical Networks," Ramon Casellas, Ricardo Martinez, Raul Munoz (CTTC, Spain) o "GMPLS OAM Tool Kit" Zafar Ali, Roberto Cassata, (Cisco, USA), T. Otani, (KDDI R&D, Japan), Marco Anisetti, Valerio Bellandi, Ernesto Damiani, Francesco Diana, Umberto Raimondi (University of Milan, Italy) o "Lessons learned from operational experience on the JGN II GMPLS network test bed" S. Okamoto and T. Otani (KDDI R&D, Japan) o "Service and Architecture of GMPLS-Controlled Photonic Internet Exchange" Yoshiaki Sone, Wataru Imajuku, Ippei Shake, Kazuhiro Matsuda (NTT, Japan), Tomohiko Kurahashi, Junichi Shimagami, Toshiya Asaba, (IIJ, Japan), Yukiyasu Tarui, Nobuhisa Miyake, Katsuyasu Toyama (Internet Multifeed, Japan) ----------------------------------------------------------------------------- Tech. Session 6: MLN Chair: Tomohiro Otani, KDDI R&D, Japan o "Is SRLG Optimization a Business Case for GMPLS Deployment?" Stefan Schnitter, Martin Horneffer (Deutsche Telekom, Germany) o "GMPLS based Multi Layer Service Network Architecture and Layer 1 On Demand Service Resource Management" Ichiro Inoue, Kaori Shimizu, Rie Hayashi, Hisashi Kojima, Kohei Shiomoto, (NTT, Japan), Shigeo Urushidani (NII, Japan) o "Next Steps for Deploying Multi-layer Traffic Engineered Networks" Steve West (Cyan Optics, USA), Peter Willis (BT, UK), Daniel King (Aria Networks, UK) ----------------------------------------------------------------------------- Poster Session ----------------------------------------------------------------------------- Day 1 (June 5, 2008) ----------------------------------------------------------------------------- Poster Session Chair: Ernesto Damiani, University of Milan, Italy o "Optical Fast Reroute," Adrian Farrel (Old Dog Consulting, UK) o "GMPLS VLAN Path Establishment using Inter-domain VLAN Tag Swapping," Kou Kikuta, Masahiro Nishida, Daisuke Ishii, Satoru Okamoto, Naoaki Yamanaka (KEIO University, Japan) o "Chromatic Dispersion Compensation Control in Dynamically Reconfigurable All-Optical Networks," Eiichi Horiuchi, Misato Kamei, Shoichiro Seno, and Yoshimasa Baba (Mitsubishi Electric Corporation, Japan) o "IGP Extentension for RWA in WSON," Jianrui Han, Dan Li, Jianhua Gao, Young Lee (Huawei Technologies, P.R.China) o "Establishing Inter-domain services," Richard Douville, Helia Pouyllau (Alcatel-lucent Bell-labs, France) o "SShared Backup Mesh Protection in PCE-based WSON networks," Greg Bernstein (Grotto Networks, USA), Young Lee (Huawei, USA) o "P2MP Path Computation & Operation in MPLS & Optical Networks," Quintin Zhao (Huawei, USA), Daniel King (Aria Networks, UK), Fabien Verhaeghe (Marben, France), Tomonori Takeda (NTT, Japan) ----------------------------------------------------------------------------- Exhibition ----------------------------------------------------------------------------- o Exhibition participants Keio University KDDI Laboratories NTT NICT NEC Anritsu ISOCORE Tokyo University Juniper Networks OIF Infinera Tellabs o Showcase Participants Kei-han-na Open Lab Lambda UTILITY ------------------------------------------------------------------------------- Sponsors ------------------------------------------------------------------------------- o Sponsored by Photonic Internet Lab. (http://www.pilab.jp) ISOCORE (http://www.isocore.com$B!K(B o Supported by Photonic Internet Forum (http://www.scat.or.jp/photonic/$B!K(B Kei-han-na Open Lab (http://www.khn-openlab.jp/bunkakai-gw/kokino-net/sousetsu/index-j.html) Council for Info-Communication Promotions Month(http://www.jtgkn.com/) *iPOP2008 is an Event of Info-Communication Promotions Month ------------------------------------------------------------------------------- Best regards, -Soichiro Araki Organization Committee Co-Chair, iPOP 2008 http://www.ipop2008.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Soichiro ARAKI System Platforms Research Laboratories, NEC Corporation E-mail: s-araki@cj.jp.nec.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ccamp@ops.ietf.org Wed May 14 00:52:59 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FB73A6853 for ; Wed, 14 May 2008 00:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGExOOXptcFf for ; Wed, 14 May 2008 00:52:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 546D73A6808 for ; Wed, 14 May 2008 00:52:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwBg8-000Lio-Ql for ccamp-data@psg.com; Wed, 14 May 2008 07:45:36 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwBfb-000LeF-Kd for ccamp@ops.ietf.org; Wed, 14 May 2008 07:45:21 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 8168E3A6853; Wed, 14 May 2008 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-path-key-ero-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080514074501.8168E3A6853@core3.amsl.com> Date: Wed, 14 May 2008 00:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : RSVP Extensions for Path Key Support Author(s) : R. Bradford, et al. Filename : draft-ietf-ccamp-path-key-ero-01.txt Pages : 8 Date : 2008-05-14 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCE supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS). This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so facilitate confiedntiality in the signaling of inter-domain TE LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-path-key-ero-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-14004042.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Wed May 14 10:38:47 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C3C3A686E for ; Wed, 14 May 2008 10:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nRkRpiaB3XD for ; Wed, 14 May 2008 10:38:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA0753A67F6 for ; Wed, 14 May 2008 10:38:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwKoS-0004li-KO for ccamp-data@psg.com; Wed, 14 May 2008 17:30:48 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JwKnl-0004fH-5w for ccamp@ops.ietf.org; Wed, 14 May 2008 17:30:27 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 08D213A6955; Wed, 14 May 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-wavelength-switched-framework-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080514173002.08D213A6955@core3.amsl.com> Date: Wed, 14 May 2008 10:30:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, Y. Lee, W. Imajuku Filename : draft-ietf-ccamp-wavelength-switched-framework-00.txt Pages : 34 Date : 2008-5-13 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switched-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-wavelength-switched-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-14102709.I-D@ietf.org> --NextPart-- From princeacetylenediurein1543656@gmail.com Thu May 15 21:27:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0313A6849; Thu, 15 May 2008 21:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.667 X-Spam-Level: X-Spam-Status: No, score=-90.667 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x2WhlJ7Ry2V; Thu, 15 May 2008 21:27:37 -0700 (PDT) Received: from tdev144-79.codetel.net.do (unknown [201.229.144.79]) by core3.amsl.com (Postfix) with SMTP id 9BF4D3A67FA; Thu, 15 May 2008 21:27:12 -0700 (PDT) X-Originating-IP: 186.96.200.233 by smtp.201.229.144.79; Fri, 16 May 2008 00:27:11 -0500 Message-ID: From: "Gene Ramos" Reply-To: "Gene Ramos" To: call-home-bounces@ietf.org Subject: Get your watch now Date: Fri, 16 May 2008 00:27:11 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://leviwilu41004.blogspot.com/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://leviwilu41004.blogspot.com/ From c7c0bf6e@ici.fr Sat May 17 01:23:08 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CB53A6846; Sat, 17 May 2008 01:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.608 X-Spam-Level: X-Spam-Status: No, score=-50.608 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3SzPv0uj4vL; Sat, 17 May 2008 01:23:07 -0700 (PDT) Received: from 199-143-223-201.adsl.terra.cl (199-143-223-201.adsl.terra.cl [201.223.143.199]) by core3.amsl.com (Postfix) with SMTP id 8421F3A699F; Sat, 17 May 2008 01:22:57 -0700 (PDT) X-Originating-IP: 188.62.68.56 by smtp.201.223.143.199; Sat, 17 May 2008 04:22:55 -0500 Message-ID: From: "Colette Dennison" Reply-To: "Colette Dennison" To: call-home-bounces@ietf.org Subject: You and a Rolex watch Date: Sat, 17 May 2008 04:22:55 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://hyguvimy77333.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://hyguvimy77333.blogspot.com/ From owner-ccamp@ops.ietf.org Sun May 18 03:57:05 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315903A6852 for ; Sun, 18 May 2008 03:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.332 X-Spam-Level: ** X-Spam-Status: No, score=2.332 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTXitc7EqlDg for ; Sun, 18 May 2008 03:57:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1054D3A6A58 for ; Sun, 18 May 2008 03:57:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JxgRc-000IJ4-Es for ccamp-data@psg.com; Sun, 18 May 2008 10:48:48 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JxgRR-000IHL-9w for ccamp@ops.ietf.org; Sun, 18 May 2008 10:48:42 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4IAmWe5017246; Sun, 18 May 2008 11:48:32 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4IAmShG017226; Sun, 18 May 2008 11:48:30 +0100 Message-ID: <027401c8b8d4$b2902db0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "BRUNGARD, DEBORAH A, ATTLABS" , References: <449B2580D802A443A923DABF3EAB82AF10F7A8D2@OCCLUST04EVS1.ugd.att.com> <449B2580D802A443A923DABF3EAB82AF111C79A8@OCCLUST04EVS1.ugd.att.com> Subject: Re: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02 Date: Sun, 18 May 2008 11:46:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, I have done a chair review on this draft and found some small editorial updates that should be made before the I-D goes forward. If the editors could resolve these and submit an update, we will be ready for Deborah to take the I-D to the IESG. Thanks, Adrian idnits == It seems as if not all pages are separated by form feeds - found 1 form feeds but 12 pages == Unused Reference: 'RFC 3473' is defined on line 406, but no explicit reference was found in the text === General points - I think you should decide whether management plane, control plane, and data plane are capitalized or not, and apply this to the whole document. - Conventionally, references (such as [RFC1234]) do not include spaces (i.e., not [RFC 1234]) === 1. Introduction s/endpoints/end-points/ OLD At least some control plane initiated aspects of a connection must be capable of being queried by the management plane. These aspects should be independent of how the connection was established. NEW At least some aspects of a control plane initiated connection must be capable of being queried by the management plane. These aspects should be independent of how the connection was established. === 2. Motivation s/or SC interoperation is achieved/or before SC interoperation is achieved/ s/is proposed as/is stated as/ s/is seen as a nice to have, or desirable, feature/is a desirable feature/ s/should be scoped as/is scoped as/ === 3. Label Switched Path Terminology s/(such as Path and Resv state)/(such as RSVP-TE [RFC3473] Path and Resv state)/ I think you should note that control plane LSPs may be visible and controlable through the management plane. That is, the control plane LSP may have been requested through a management plane operation, and can be reported and inspected by/at the transit LSR. Further, it is generally the case that management plane operations can be carried out on the resources of active control plane LSPs even at transit LSRs. You can then say that this is not the function that you are talking about. === 4. LSP within GMPLS Control Plane Include a refernce to RFC 3945 as you are talking about GMPLS architecture. === 4.1. Resource Ownership At the end of the first paragraph, you have... Note that the management plane assigns resources to the control plane. I think this is confusing in the context of the rest of the text in the paragrpah that defines 'ownership' of resources in relation to the setup of an LSP. Doesn't the sentence actually belong in the next paragraph? I.e., Note that the management plane assigns resources as available for ownership by the control plane. Or even just delete this sentence. === 4.2. Setting Up a GMPLS Controlled Network You have... When converting from an SC to a PC, the management plane must change the owner of each hop. Somehow, then the instance in the control plane must be removed without affecting the data plane. This may best be done via a make before break operation. This last sentence is odd! There is no "make-before-break operation" to be performed as there is no change in the data plane. I suggest that you simply remove this sentence which, in any case, is pre-judging the solution (which this document should avoid doing). === 5.1. PC to SC/SPC Conversion s/Next step in such conversion/The next step in this conversion/ You have... In this case a network upgrade by a Control Plane coverage extension may be required. Huh? The phrase "Control Plane coverage extension" didn't mean anything to me (although I can make some guesses). Can you clarify in the text, please. === 6. Requirements Suggest you add... Notation from [RFC2119] is used to clarify the level of each requirement. === 6.2. No Disruption of User Traffic SC to PC conversion and vice-versa shall occur without generating s/shall/SHALL/ ? === 6.5. Synchronization of state among nodes during conversion Please capitalize the section heading It MUST be assured that the state of the LSP is synchronized among all nodes traversed by it before proceeding to the conversion. Does "before proceeding to the conversion" mean "before the conversion is considered complete"? From cachorro@tafisa.com.br Sun May 18 08:31:11 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C981C3A67AC; Sun, 18 May 2008 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.296 X-Spam-Level: X-Spam-Status: No, score=-82.296 tagged_above=-999 required=5 tests=[FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.935, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN2uTSyt2QNm; Sun, 18 May 2008 08:31:11 -0700 (PDT) Received: from pc-145-14-83-200.cm.vtr.net (pc-145-14-83-200.cm.vtr.net [200.83.14.145]) by core3.amsl.com (Postfix) with SMTP id 69C273A689C; Sun, 18 May 2008 08:30:55 -0700 (PDT) X-Originating-IP: 124.54.244.50 by smtp.200.83.14.145; Sun, 18 May 2008 11:30:56 -0500 Message-ID: From: "Ben Bowles" Reply-To: "Ben Bowles" To: cancer@ietf.org Subject: Elegant watches for less than half Date: Sun, 18 May 2008 11:30:56 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://hygocuxi67353.blogspot.com/ From cac@cochranealliance.com Sun May 18 08:33:17 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72353A67AC; Sun, 18 May 2008 08:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.54 X-Spam-Level: X-Spam-Status: No, score=-69.54 tagged_above=-999 required=5 tests=[FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.509, RCVD_IN_XBL=2.896, RDNS_NONE=0.1, REPLICA_WATCH=3.396, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.617, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz+Z0rBbAxk8; Sun, 18 May 2008 08:33:16 -0700 (PDT) Received: from 190-51-116-7.speedy.com.ar (unknown [190.51.116.7]) by core3.amsl.com (Postfix) with SMTP id DD2BE28C244; Sun, 18 May 2008 08:33:04 -0700 (PDT) X-Originating-IP: 224.96.176.102 by smtp.190.51.116.7; Sun, 18 May 2008 11:33:03 -0500 Message-ID: From: "Troy Goodman" Reply-To: "Troy Goodman" To: call-home-bounces@ietf.org Subject: Replicas will save you thousands Date: Sun, 18 May 2008 11:33:03 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit How about making your friends jealous and saving a lot of money doing it? Forget about spending thousands of dollars on a new Rolex watch! Instead, visit the newly redesigned Prestige Replicas and buy yourself a beautiful, one of a kind Rolex Datejust watch! http://xuhywalu06536.blogspot.com/ Of course, we're talking about replica watches, not the overpriced originals... After all, our Rolex Datejusts offer the same precise functionality and exact look than their costly counterparts, but you can buy yours for just a couple of hundred bucks. So, come aboard Prestige Replicas and take advantage of our extensive collection of replica Rolex watches, our superb customer service and our super low prices! http://xuhywalu06536.blogspot.com/ From c.lenaerts@waypoint-design.com Sun May 18 13:27:09 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473113A6800; Sun, 18 May 2008 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.263 X-Spam-Level: X-Spam-Status: No, score=-76.263 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_DSBL=0.753, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7a9SvQ+EATC; Sun, 18 May 2008 13:27:08 -0700 (PDT) Received: from cliente-10702.iberbanda.es (unknown [82.198.105.204]) by core3.amsl.com (Postfix) with SMTP id 38BFA3A690F; Sun, 18 May 2008 13:26:43 -0700 (PDT) X-Originating-IP: 168.170.57.130 by smtp.82.198.105.204; Sun, 18 May 2008 16:26:44 -0500 Message-ID: From: "Nona Black" Reply-To: "Nona Black" To: atompub-archive@megatron.ietf.org Subject: Replica watches made easy Date: Sun, 18 May 2008 16:26:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://rywafyko20118.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://rywafyko20118.blogspot.com/ From owner-ccamp@ops.ietf.org Sun May 18 14:20:33 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B1E3A67FD for ; Sun, 18 May 2008 14:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.518 X-Spam-Level: ** X-Spam-Status: No, score=2.518 tagged_above=-999 required=5 tests=[AWL=-0.187, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXDABLjYE59l for ; Sun, 18 May 2008 14:20:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23A823A6834 for ; Sun, 18 May 2008 14:20:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JxqCX-000CRO-A3 for ccamp-data@psg.com; Sun, 18 May 2008 21:13:53 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JxqCL-000CPh-Ho for ccamp@ops.ietf.org; Sun, 18 May 2008 21:13:47 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4ILDXKc027896; Sun, 18 May 2008 22:13:36 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4ILDTAV027890; Sun, 18 May 2008 22:13:32 +0100 Message-ID: <028d01c8b92c$02eb8c30$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "BRUNGARD, DEBORAH A, ATTLABS" , References: <449B2580D802A443A923DABF3EAB82AF1112CF11@OCCLUST04EVS1.ugd.att.com> Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Date: Sun, 18 May 2008 22:13:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Well written draft. Thanks. Here are some comments. Most of them are small editorial issues. Regards, Adrian === idnits tmp/draft-ietf-ccamp-gr-description-02.txt(191): Line is too long: the offending characters are ',' === 1. Introduction Recovery Label object Please be consistent with the names for all objects within this I-D. Mainly you use upper case, for example, RECOVERY_LABEL object s/provides and informational/provides an informational/ === 2.1. Procedures defined in [RFC3473] Please capitalise section heading. s/2) Recovers its RSVP state/2) Recover its RSVP state/ s/state in data plane/state in the data plane/ s/is not existed/does not exist/ s/state in data plane is existed/state in the data plane exists/ You have: For the Restarting Node: [SNIP] 4) [SNIP] In addition, if the node is not the tail-end of the LSP, the corresponding outgoing Path messages is sent with the incoming label from that entry carried in the UPSTREAM_LABEL object. "incoming label from that entry" is correct, but may be confusing. How about... In addition, if the node is not the tail-end of the LSP, the incoming label on the downstream interface is retrieved from the forwarding state on the restarting node and set in the UPSTREAM_LABEL object in the Path message sent to the downstream neighbor. s/1) Sends the Path message/1) Sends a Path message/ === 2.2. Procedures defined in [RFC5063] s/in [RFC5063] which is called the/in [RFC5063] called the / s/From the received Path message the following state can be recovered:/ The following state can be recovered from the received Path message:/ s/From the received RecoveryPath message the following state can be recovered:/ The following state can be recovered from the received RecoveryPath message:/ s/either by regular Path message or RecoveryPath message, and Resv message./ either from the regular Path and Resv messages, or from the RecoveryPath message./ === 3. Multiple Node Restart Scenarios s/Note that if multi nodes/Note that if multiple nodes/ === 5.2.2. Procedures for Scenario 2 s/node(Node A)/node (Node A)/ === 5.2.3. Procedures for scenario 3 Please capitalise section heading. s/on the nodes that are waiting/on the node that is waiting/ === 5.2.4. Procedures for scenario 4 Please capitalise section heading. You have: In the event that Node B never restarts, management plane intervention may be used at Node A to clean up any LSP state restored from the management plane or from local configuration. More importantly, management plane action is needed to clean up the data plane. === 5.2.5. Procedures for scenario 5 Please capitalise section heading. You have: In this scenario the Egress node (Node D) restarts, and its upstream neighbor (Node C) has not restarted. In this case, the Egress node is completely unaware of the LSPs. It has no downstream neighbor to help it, and no management plane or configuration information. The Egress node must simply wait until its upstream neighbor restarts and gives it the information as Path messages carrying RECOVERY_LABEL objects. It is not quite the case that the egress is "completely unaware" of the LSP as the data plane will be set up and carrying data (as described in the next section). === 6. Clarification of Restarting Node Procedure In the figure, you have X(CON deletion) X (CON deletion) I suggest you replace this with X(LSP deletion) X (LSP deletion) Please add a caption for the figure. Such as, Figure 2 Message flow for accidental LSP deletion c/hello/Hello/ (several times) To resolve the aforementioned problem, the following procedures are proposed and are meant to work together with the recovery procedures documented in [RFC3473]. Here, it is assumed that the restarting node and the neighboring node(s) support Hello extension as documented in [RFC3209] and recovery procedures documented in [RFC3473]. This paragraph implies that there *are* new procedures defined in this document contrary to the promise in the Abstract and Introduction. I suggest you change the text as follows... To resolve the aforementioned problem, the following procedures which are implicit in [RFC3473] and [RFC5063] should be followed. These procedures work together with the recovery procedures documented in [RFC3473]. Here, it is assumed that the restarting node and the neighboring node(s) support Hello extension as documented in [RFC3209] and recovery procedures documented in [RFC3473]. === 7. Security Considerations We had some debate with the Security ADs when RFC 5063 was processed. We need to fill out the text in this section a little to reflect those comments. I suggest replacing the existing text with the following... This document clarifies the procedures defined in [RFC3473] and [RFC5063] to be performed on RSVP agents that neighbor one or more restarting RSVP agents. It does not introduce any new procedures and, therefore, does not introduce any new security risks or issues. In the case of the control plane in general, and the RSVP agent in particular, where one or more nodes carrying one or more LSPs are restarted due to external attacks, the procedures defined in [RFC5063] and described in this document provide the ability for the restarting RSVP agents to recover the RSVP state in each restarting node corresponding to the LSPs, with the least possible perturbation to the rest of the network. These procedures can be considered to provide mechanisms by which the GMPLS network can recover from physical attacks or from attacks on remotely controlled power supplies. The procedures described are such that, only the neighboring RSVP agents should notice the restart of a node, and hence only they need to perform additional processing. This allows for a network with active LSPs to recover LSP state gracefully from an external attack, without perturbing the data/forwarding plane state, and without propagating the error condition in the control or data plane. In other words, the effect of the restart (which might be the result of an attack) does not spread into the network. Note that concern has been expressed about the vulnerability of a restarting node to false messages received from its neighbors. For example, a restarting node might receive a false Path message with a Recovery Label object from an upstream neighbor, or a false RecoveryPath message from its downstream neighbor. This situation might arise in one of four cases: - The message is spoofed and does not come from the neighbor at all. - The message has been modified as it was travelling from the neighbor. - The neighbor is defective and has generated a message in error. - The neighbor has been subverted and has a "rogue" RSVP agent. The first two cases may be handled using standard RSVP authentication and integrity procedures [RFC3209], [RFC3473]. If the operator is particularly worried, the control plane may be operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411] Protection against defective or rogue RSVP implementations is generally hard to impossible. Neighbor-to-neighbor authentication and integrity validation is, by definition, ineffective in these situations. For example, if a neighbor node sends a Resv during normal LSP setup, and if that message carries a GENERALIZED_LABEL object carrying an incorrect label value, then the receiving LSR will use the supplied value and the LSP will be set up incorrectly. Alternatively, if a Path message is modified by an upstream LSR to change the destination and explicit route, there is no way for the downstream LSR to detect this, and the LSP may be set up to the wrong destination. Furthermore, the upstream LSR could disguise this fact by modifying the recorded route reported in the Resv message. Thus, these issues are in no way specific to the restart case, do not cause any greater or different problems from the normal case, and do not warrant specific security measure applicable to restart scenarios. Note that the RSVP POLICY object [RFC2205] provides a scope by which secure end-to-end checks could be applied. However, very little definition of the use of this object has been made to date. See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS networks. === 10.2. Informative References Replace with... [MPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework, work in progress. [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap," November 1998. [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet Protocol," December 2005. [RFC4302] S. Kent, "IP Authentication Header," December 2005. [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", December 2005. [RFC4835] V. Manral, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", April 2007. From caceres@entercomunicaciones.com Sun May 18 23:18:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0193A68A9; Sun, 18 May 2008 23:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.61 X-Spam-Level: X-Spam-Status: No, score=-23.61 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxvEa0NygIoV; Sun, 18 May 2008 23:18:37 -0700 (PDT) Received: from tdev132-28.codetel.net.do (unknown [190.80.132.28]) by core3.amsl.com (Postfix) with SMTP id DD2E528C481; Sun, 18 May 2008 23:18:12 -0700 (PDT) X-Originating-IP: 212.112.183.234 by smtp.190.80.132.28; Mon, 19 May 2008 02:18:11 -0500 Message-ID: From: "Gale Cormier" Reply-To: "Gale Cormier" To: call-home-bounces@ietf.org Subject: Save 80% on Brand name replica watches Date: Mon, 19 May 2008 02:18:11 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://pabuxano66441.shheus.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://pabuxano66441.shheus.com/ From owner-ccamp@ops.ietf.org Mon May 19 00:27:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B00F28C5F5 for ; Mon, 19 May 2008 00:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjbpOUaSnIvB for ; Mon, 19 May 2008 00:27:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E3D33A69E5 for ; Mon, 19 May 2008 00:27:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jxzao-000GlN-Qp for ccamp-data@psg.com; Mon, 19 May 2008 07:15:34 +0000 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JxzaY-000GjI-RM for ccamp@ops.ietf.org; Mon, 19 May 2008 07:15:28 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1300ABPTHETJ@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 19 May 2008 15:15:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1300BK7THEN7@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 19 May 2008 15:15:14 +0800 (CST) Received: from l37133 ([10.70.77.61]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1300FZATHEVT@szxml04-in.huawei.com> for ccamp@ops.ietf.org; Mon, 19 May 2008 15:15:14 +0800 (CST) Date: Mon, 19 May 2008 15:15:13 +0800 From: Dan Li Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 To: Adrian Farrel , "BRUNGARD, DEBORAH A, ATTLABS" , ccamp@ops.ietf.org Message-id: <110801c8b980$14fa4e80$3d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <449B2580D802A443A923DABF3EAB82AF1112CF11@OCCLUST04EVS1.ugd.att.com> <028d01c8b92c$02eb8c30$0200a8c0@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Adrian, Thanks for the very detailed comments! The proposed text for most of the editorial issues will be accepted in the next version. Still have several issues letf, and II proposed the text: > === > 5.2.4. Procedures for scenario 4 > > Please capitalise section heading. > > You have: > In the event that Node B never restarts, management plane > intervention may be used at Node A to clean up any LSP state > restored from the management plane or from local configuration. > More importantly, management plane action is needed to clean up the > data plane. > [Dan Li] Proposed text: "In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP state restored from the management plane or from local configuration." > === > 5.2.5. Procedures for scenario 5 > > Please capitalise section heading. > > You have: > In this scenario the Egress node (Node D) restarts, and its > upstream neighbor (Node C) has not restarted. In this case, the > Egress node is completely unaware of the LSPs. It has no downstream > neighbor to help it, and no management plane or configuration > information. The Egress node must simply wait until its upstream > neighbor restarts and gives it the information as Path messages > carrying RECOVERY_LABEL objects. > It is not quite the case that the egress is "completely unaware" of > the LSP as the data plane will be set up and carrying data (as > described in the next section). > [Dan Li] Proposed text: "...In this case, the Egress node may not aware of the LSPs...." > 7. Security Considerations [SNIP] > Note that the RSVP POLICY object [RFC2205] provides a scope by which > secure end-to-end checks could be applied. However, very little > definition of the use of this object has been made to date. [Dan Li] Do you mean RSVP POLICY_DATA object described in RFC 2205? Thanks, Dan ----- Original Message ----- From: "Adrian Farrel" To: "BRUNGARD, DEBORAH A, ATTLABS" ; Sent: Monday, May 19, 2008 5:13 AM Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 > Hi, > > Well written draft. Thanks. > > Here are some comments. Most of them are small editorial issues. > > Regards, > Adrian > > === > idnits > tmp/draft-ietf-ccamp-gr-description-02.txt(191): Line is too long: the > offending characters are ',' > > === > 1. Introduction > > Recovery Label object > > Please be consistent with the names for all objects within this I-D. > Mainly you use upper case, for example, RECOVERY_LABEL object > > s/provides and informational/provides an informational/ > > === > 2.1. Procedures defined in [RFC3473] > > Please capitalise section heading. > > s/2) Recovers its RSVP state/2) Recover its RSVP state/ > > s/state in data plane/state in the data plane/ > > s/is not existed/does not exist/ > > s/state in data plane is existed/state in the data plane exists/ > > You have: > > For the Restarting Node: > [SNIP] > 4) > [SNIP] > In addition, if the node is not > the tail-end of the LSP, the corresponding outgoing Path messages is > sent with the incoming label from that entry carried in the > UPSTREAM_LABEL object. > "incoming label from that entry" is correct, but may be confusing. > How about... > In addition, if the node is not the tail-end of the LSP, the incoming > label on the downstream interface is retrieved from the forwarding > state on the restarting node and set in the UPSTREAM_LABEL object in > the Path message sent to the downstream neighbor. > > s/1) Sends the Path message/1) Sends a Path message/ > > === > 2.2. Procedures defined in [RFC5063] > > s/in [RFC5063] which is called the/in [RFC5063] called the / > > s/From the received Path message the following state can be recovered:/ > The following state can be recovered from the received Path message:/ > > s/From the received RecoveryPath message the following state can be > recovered:/ > The following state can be recovered from the received RecoveryPath > message:/ > > s/either by regular Path message or RecoveryPath message, and Resv message./ > either from the regular Path and Resv messages, or from the RecoveryPath > message./ > > === > 3. Multiple Node Restart Scenarios > > s/Note that if multi nodes/Note that if multiple nodes/ > > === > 5.2.2. Procedures for Scenario 2 > > s/node(Node A)/node (Node A)/ > > === > 5.2.3. Procedures for scenario 3 > > Please capitalise section heading. > > s/on the nodes that are waiting/on the node that is waiting/ > > === > 5.2.4. Procedures for scenario 4 > > Please capitalise section heading. > > You have: > In the event that Node B never restarts, management plane > intervention may be used at Node A to clean up any LSP state > restored from the management plane or from local configuration. > More importantly, management plane action is needed to clean up the > data plane. > > === > 5.2.5. Procedures for scenario 5 > > Please capitalise section heading. > > You have: > In this scenario the Egress node (Node D) restarts, and its > upstream neighbor (Node C) has not restarted. In this case, the > Egress node is completely unaware of the LSPs. It has no downstream > neighbor to help it, and no management plane or configuration > information. The Egress node must simply wait until its upstream > neighbor restarts and gives it the information as Path messages > carrying RECOVERY_LABEL objects. > It is not quite the case that the egress is "completely unaware" of > the LSP as the data plane will be set up and carrying data (as > described in the next section). > > === > 6. Clarification of Restarting Node Procedure > > In the figure, you have > X(CON deletion) X (CON deletion) > I suggest you replace this with > X(LSP deletion) X (LSP deletion) > > Please add a caption for the figure. Such as, > > Figure 2 Message flow for accidental LSP deletion > > c/hello/Hello/ (several times) > > To resolve the aforementioned problem, the following procedures are > proposed and are meant to work together with the recovery > procedures documented in [RFC3473]. Here, it is assumed that the > restarting node and the neighboring node(s) support Hello extension > as documented in [RFC3209] and recovery procedures documented in > [RFC3473]. > This paragraph implies that there *are* new procedures defined in this > document contrary to the promise in the Abstract and Introduction. > I suggest you change the text as follows... > To resolve the aforementioned problem, the following procedures which > are implicit in [RFC3473] and [RFC5063] should be followed. These > procedures work together with the recovery procedures documented in > [RFC3473]. Here, it is assumed that the restarting node and the > neighboring node(s) support Hello extension as documented in > [RFC3209] and recovery procedures documented in [RFC3473]. > > === > 7. Security Considerations > > We had some debate with the Security ADs when RFC 5063 was processed. We > need to fill out the text in this section a little to reflect those > comments. > > I suggest replacing the existing text with the following... > > This document clarifies the procedures defined in [RFC3473] and > [RFC5063] to be performed on RSVP agents that neighbor one or more > restarting RSVP agents. It does not introduce any new procedures and, > therefore, does not introduce any new security risks or issues. > > In the case of the control plane in general, and the RSVP agent in > particular, where one or more nodes carrying one or more LSPs are > restarted due to external attacks, the procedures defined in > [RFC5063] and described in this document provide the ability for > the restarting RSVP agents to recover the RSVP state in each > restarting node corresponding to the LSPs, with the least possible > perturbation to the rest of the network. These procedures can be > considered to provide mechanisms by which the GMPLS network can > recover from physical attacks or from attacks on remotely controlled > power supplies. > > The procedures described are such that, only the neighboring RSVP > agents should notice the restart of a node, and hence only they need > to perform additional processing. This allows for a network with > active LSPs to recover LSP state gracefully from an external attack, > without perturbing the data/forwarding plane state, and without > propagating the error condition in the control or data plane. In > other words, the effect of the restart (which might be the result of > an attack) does not spread into the network. > > Note that concern has been expressed about the vulnerability of a > restarting node to false messages received from its neighbors. For > example, a restarting node might receive a false Path message with a > Recovery Label object from an upstream neighbor, or a false > RecoveryPath message from its downstream neighbor. This situation > might arise in one of four cases: > > - The message is spoofed and does not come from the neighbor at all. > - The message has been modified as it was travelling from the > neighbor. > - The neighbor is defective and has generated a message in error. > - The neighbor has been subverted and has a "rogue" RSVP agent. > > The first two cases may be handled using standard RSVP authentication > and integrity procedures [RFC3209], [RFC3473]. If the operator is > particularly worried, the control plane may be operated using IPsec > [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411] > > Protection against defective or rogue RSVP implementations is > generally hard to impossible. Neighbor-to-neighbor authentication > and integrity validation is, by definition, ineffective in these > situations. For example, if a neighbor node sends a Resv during > normal LSP setup, and if that message carries a GENERALIZED_LABEL > object carrying an incorrect label value, then the receiving LSR will > use the supplied value and the LSP will be set up incorrectly. > Alternatively, if a Path message is modified by an upstream LSR to > change the destination and explicit route, there is no way for the > downstream LSR to detect this, and the LSP may be set up to the wrong > destination. Furthermore, the upstream LSR could disguise this fact by > modifying the recorded route reported in the Resv message. Thus, these > issues are in no way specific to the restart case, do not cause any > greater or different problems from the normal case, and do not warrant > specific security measure applicable to restart scenarios. > > Note that the RSVP POLICY object [RFC2205] provides a scope by which > secure end-to-end checks could be applied. However, very little > definition of the use of this object has been made to date. > > See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS > networks. > > > === > 10.2. Informative References > > Replace with... > > [MPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS > Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework, work > in progress. > > [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document > Roadmap," November 1998. > > [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet > Protocol," December 2005. > > [RFC4302] S. Kent, "IP Authentication Header," December 2005. > > [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) > Protocol", December 2005. > > [RFC4835] V. Manral, "Cryptographic Algorithm Implementation > Requirements for Encapsulating Security Payload (ESP) and > Authentication Header (AH)", April 2007. > > > > > From owner-ccamp@ops.ietf.org Mon May 19 00:49:44 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98153A697C for ; Mon, 19 May 2008 00:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.312 X-Spam-Level: ** X-Spam-Status: No, score=2.312 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6PScT7OqUkM for ; Mon, 19 May 2008 00:49:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37FC93A6E36 for ; Mon, 19 May 2008 00:48:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy01t-000Jat-Hl for ccamp-data@psg.com; Mon, 19 May 2008 07:43:33 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy01i-000JZP-1g for ccamp@ops.ietf.org; Mon, 19 May 2008 07:43:27 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4J7h7Z3031164; Mon, 19 May 2008 08:43:07 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4J7h5f1031146; Mon, 19 May 2008 08:43:06 +0100 Message-ID: <02fb01c8b983$f66cf810$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dan Li" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , References: <449B2580D802A443A923DABF3EAB82AF1112CF11@OCCLUST04EVS1.ugd.att.com> <028d01c8b92c$02eb8c30$0200a8c0@your029b8cecfe> <110801c8b980$14fa4e80$3d4d460a@china.huawei.com> Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Date: Mon, 19 May 2008 08:42:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Dan, Thanks for the speedy response. Comments in line. >> 5.2.4. Procedures for scenario 4 >> >> Please capitalise section heading. >> >> You have: >> In the event that Node B never restarts, management plane >> intervention may be used at Node A to clean up any LSP state >> restored from the management plane or from local configuration. >> More importantly, management plane action is needed to clean up the >> data plane. >> > [Dan Li] Proposed text: > "In the event that Node B never restarts, management plane intervention is > needed at Node A to clean up any LSP state restored from the management > plane or from local configuration." Hmmm, maybe missed the point about the data plane? How about... In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP control plane state restored from the management plane or from local configuration, and to release any data plane resources." >> 5.2.5. Procedures for scenario 5 >> >> Please capitalise section heading. >> >> You have: >> In this scenario the Egress node (Node D) restarts, and its >> upstream neighbor (Node C) has not restarted. In this case, the >> Egress node is completely unaware of the LSPs. It has no downstream >> neighbor to help it, and no management plane or configuration >> information. The Egress node must simply wait until its upstream >> neighbor restarts and gives it the information as Path messages >> carrying RECOVERY_LABEL objects. >> It is not quite the case that the egress is "completely unaware" of >> the LSP as the data plane will be set up and carrying data (as >> described in the next section). >> > [Dan Li] Proposed text: > "...In this case, the Egress node may not aware of the LSPs...." Well, I would suggest.... In this scenario the Egress node (Node D) restarts, and its upstream neighbor (Node C) has not restarted. In this case, the Egress node may have no control plane state relating to the LSPs. It has no downstream neighbor to help it, and no management plane or configuration information, although there will be data plane state for the LSP. The Egress node must simply wait until its upstream neighbor restarts and gives it the information as Path messages carrying RECOVERY_LABEL objects. >> 7. Security Considerations > [SNIP] >> Note that the RSVP POLICY object [RFC2205] provides a scope by which >> secure end-to-end checks could be applied. However, very little >> definition of the use of this object has been made to date. > > [Dan Li] Do you mean RSVP POLICY_DATA object described in RFC 2205? Ah, yes. Good catch. Cheers, Adrian From owner-ccamp@ops.ietf.org Mon May 19 02:51:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161DF3A6AED for ; Mon, 19 May 2008 02:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4ofKKcv5oV1 for ; Mon, 19 May 2008 02:51:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B7D13A6916 for ; Mon, 19 May 2008 02:51:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy1w0-0006mn-Il for ccamp-data@psg.com; Mon, 19 May 2008 09:45:36 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy1vT-0006hn-Vs for ccamp@ops.ietf.org; Mon, 19 May 2008 09:45:20 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id F28AE28C236; Mon, 19 May 2008 02:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080519094501.F28AE28C236@core3.amsl.com> Date: Mon, 19 May 2008 02:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : draft-ietf-ccamp-pc-and-sc-reqs-03.txt Author(s) : D. Caviglia, D. Li Filename : draft-ietf-ccamp-pc-and-sc-reqs-03.txt Pages : 12 Date : 2008-05-19 From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-pc-and-sc-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-19023916.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon May 19 03:35:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687C428C159 for ; Mon, 19 May 2008 03:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HygyDPWqYCj6 for ; Mon, 19 May 2008 03:35:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7504728C151 for ; Mon, 19 May 2008 03:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy2dS-000BjA-DB for ccamp-data@psg.com; Mon, 19 May 2008 10:30:30 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy2d1-000Bg0-9V for ccamp@ops.ietf.org; Mon, 19 May 2008 10:30:15 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 425E13A6E37; Mon, 19 May 2008 03:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080519103001.425E13A6E37@core3.amsl.com> Date: Mon, 19 May 2008 03:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : draft-ietf-ccamp-pc-and-sc-reqs-04.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-and-sc-reqs-04.txt Pages : 11 Date : 2008-05-19 From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-pc-and-sc-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-19032752.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon May 19 09:44:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD30F28C6B4 for ; Mon, 19 May 2008 09:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it1Cj-4MNCzv for ; Mon, 19 May 2008 09:43:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A5CC3A6E9E for ; Mon, 19 May 2008 09:40:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy8Fu-0007Oa-Lt for ccamp-data@psg.com; Mon, 19 May 2008 16:30:34 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jy8FQ-0007LY-AW for ccamp@ops.ietf.org; Mon, 19 May 2008 16:30:18 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 302B93A69FD; Mon, 19 May 2008 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080519163002.302B93A69FD@core3.amsl.com> Date: Mon, 19 May 2008 09:30:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Description of the RSVP-TE Graceful Restart Procedures Author(s) : D. Li Filename : draft-ietf-ccamp-gr-description-03.txt Pages : 19 Date : 2008-5-19 The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gr-description-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-19092807.I-D@ietf.org> --NextPart-- From c.germak@artsgazette.com Mon May 19 14:00:27 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9980E3A69E0; Mon, 19 May 2008 14:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -55.756 X-Spam-Level: X-Spam-Status: No, score=-55.756 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJcnOusW05sM; Mon, 19 May 2008 14:00:26 -0700 (PDT) Received: from 201-66-122-10.ctame700.dsl.brasiltelecom.net.br (201-66-122-10.ctame700.dsl.brasiltelecom.net.br [201.66.122.10]) by core3.amsl.com (Postfix) with SMTP id 120EE3A6B83; Mon, 19 May 2008 14:00:04 -0700 (PDT) X-Originating-IP: 110.244.180.185 by smtp.201.66.122.10; Mon, 19 May 2008 17:00:02 -0500 Message-ID: From: "Lawrence Walsh" Reply-To: "Lawrence Walsh" To: call-home-bounces@ietf.org Subject: Impressive Glashutte timepieces Date: Mon, 19 May 2008 17:00:02 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://nirakynypek84.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://nirakynypek84.blogspot.com/ From c.vanherp@rotim.com Mon May 19 17:42:28 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758813A6B39; Mon, 19 May 2008 17:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.766 X-Spam-Level: X-Spam-Status: No, score=-79.766 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUCbDO7VdGIh; Mon, 19 May 2008 17:42:27 -0700 (PDT) Received: from 201-255-10-157.mrse.com.ar (unknown [201.255.10.157]) by core3.amsl.com (Postfix) with SMTP id 4C16F3A6B26; Mon, 19 May 2008 17:42:13 -0700 (PDT) X-Originating-IP: 17.37.196.162 by smtp.201.255.10.157; Mon, 19 May 2008 20:42:14 -0500 Message-ID: From: "Galen Rainey" Reply-To: "Galen Rainey" To: atompub-archive@megatron.ietf.org Subject: Save thousands... no one will know Date: Mon, 19 May 2008 20:42:14 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://nuvohehenyd04.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://nuvohehenyd04.blogspot.com/ From c.marks@antonette.com Tue May 20 05:50:52 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744763A69B6; Tue, 20 May 2008 05:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.543 X-Spam-Level: X-Spam-Status: No, score=-19.543 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8zuXVWb6xyA; Tue, 20 May 2008 05:50:51 -0700 (PDT) Received: from 200-122-127-227.dsl.prima.net.ar (200-122-127-227.dsl.prima.net.ar [200.122.127.227]) by core3.amsl.com (Postfix) with SMTP id D57DC3A6881; Tue, 20 May 2008 05:49:28 -0700 (PDT) X-Originating-IP: 230.32.174.240 by smtp.200.122.127.227; Tue, 20 May 2008 08:49:26 -0500 Message-ID: From: "Elmer Zimmerman" Reply-To: "Elmer Zimmerman" To: call-home-bounces@ietf.org Subject: Classy, new and inexpensive watches Date: Tue, 20 May 2008 08:49:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://www.annsidn.com/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://www.annsidn.com/ No virus found in this outgoing message Checked by PC Tools AntiVirus (4.0.0.26 - 10.072.022). http://www.pctools.com/free-antivirus/ From c.nipkow@quartierkultur-kreis6.ch Wed May 21 11:00:27 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F327928C210; Wed, 21 May 2008 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.683 X-Spam-Level: **** X-Spam-Status: No, score=4.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yljgolX7-X5T; Wed, 21 May 2008 11:00:25 -0700 (PDT) Received: from cable201-233-159-41.epm.net.co (cable201-233-159-41.epm.net.co [201.233.159.41]) by core3.amsl.com (Postfix) with SMTP id C35893A69B0; Wed, 21 May 2008 11:00:04 -0700 (PDT) X-Originating-IP: 178.30.116.46 by smtp.201.233.159.41; Wed, 21 May 2008 14:00:09 -0500 Message-ID: From: "Pat Gilmore" Reply-To: "Pat Gilmore" To: atompub-archive@megatron.ietf.org Subject: Replica watch is a perfect gift Date: Wed, 21 May 2008 14:00:09 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www.adieks.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www.adieks.com/ From ca@mrsteam.com Wed May 21 19:51:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0428A3A680D; Wed, 21 May 2008 19:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.256 X-Spam-Level: X-Spam-Status: No, score=-21.256 tagged_above=-999 required=5 tests=[AWL=-48.284, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJj6g65c3QAe; Wed, 21 May 2008 19:51:28 -0700 (PDT) Received: from 190-51-103-130.speedy.com.ar (unknown [190.51.103.130]) by core3.amsl.com (Postfix) with SMTP id 5FFFD28C206; Wed, 21 May 2008 19:51:05 -0700 (PDT) X-Originating-IP: 0.91.25.105 by smtp.190.51.103.130; Wed, 21 May 2008 22:51:05 -0500 Message-ID: From: "Delbert Hatfield" Reply-To: "Delbert Hatfield" To: call-home-bounces@ietf.org Subject: Replica watches made easy Date: Wed, 21 May 2008 22:51:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://www.annsidn.com/ From c.unfried@secure.medicalnet.at Thu May 22 12:05:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D033A6B2F; Thu, 22 May 2008 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.626 X-Spam-Level: X-Spam-Status: No, score=-72.626 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxwIODdaMrWo; Thu, 22 May 2008 12:05:24 -0700 (PDT) Received: from 39-141-223-201.adsl.terra.cl (39-141-223-201.adsl.terra.cl [201.223.141.39]) by core3.amsl.com (Postfix) with SMTP id 4ADEF28C161; Thu, 22 May 2008 12:02:21 -0700 (PDT) X-Originating-IP: 144.223.155.180 by smtp.201.223.141.39; Thu, 22 May 2008 15:02:21 -0500 Message-ID: From: "Morton Quintero" Reply-To: "Morton Quintero" To: atompub-archive@megatron.ietf.org Subject: Beautiful Rado watches for less Date: Thu, 22 May 2008 15:02:21 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://wuhyluhakyr77.blogspot.com/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://wuhyluhakyr77.blogspot.com/ From owner-ccamp@ops.ietf.org Fri May 23 11:12:53 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA43028C2A1 for ; Fri, 23 May 2008 11:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yzAR-mGolKW for ; Fri, 23 May 2008 11:12:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D21EA28C1B2 for ; Fri, 23 May 2008 11:12:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jzbbf-0003fX-Vl for ccamp-data@psg.com; Fri, 23 May 2008 18:03:07 +0000 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JzbbC-0003bj-Oy for ccamp@ops.ietf.org; Fri, 23 May 2008 18:02:53 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-11.tower-203.messagelabs.com!1211565747!20986997!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 27508 invoked from network); 23 May 2008 18:02:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 23 May 2008 18:02:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4NI2Z74006089 for ; Fri, 23 May 2008 14:02:35 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4NI2XBj006065 for ; Fri, 23 May 2008 14:02:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BCFF.2CCD7D79" Subject: Working Group Last Call Completed: draft-ietf-ccamp-gr-description-02 Date: Fri, 23 May 2008 14:02:32 -0400 Message-ID: In-Reply-To: <449B2580D802A443A923DABF3EAB82AF1112CF11@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call Completed: draft-ietf-ccamp-gr-description-02 Thread-Index: AcivvDwYh3PM2WbnQICkg9X3bgptaANQnNdA References: <449B2580D802A443A923DABF3EAB82AF1112CF11@OCCLUST04EVS1.ugd.att.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BCFF.2CCD7D79 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable We completed the Last Call with comments incorporated in: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.t xt =20 I'll do the document shepherding. =20 Thanks, Deborah ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, May 06, 2008 5:01 PM To: ccamp@ops.ietf.org Subject: Working Group Last Call: draft-ietf-ccamp-gr-description-02 CCAMP, =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.t xt =20 Please send your comments to the mailing list prior to EOB May 20. =20 Adrian and Deborah ------_=_NextPart_001_01C8BCFF.2CCD7D79 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
We completed the Last Call with comments = incorporated=20 in:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-descri= ption-03.txt
 
I'll do the document = shepherding.
 
Thanks,
Deborah

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, May 06, 2008 5:01 PM
To:=20 ccamp@ops.ietf.org
Subject: Working Group Last Call:=20 draft-ietf-ccamp-gr-description-02

CCAMP,
 
This is to=20 initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-descri= ption-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 20.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8BCFF.2CCD7D79-- From c03305df@adriennejohnson.com Fri May 23 23:27:36 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE5E3A6A16; Fri, 23 May 2008 23:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.089 X-Spam-Level: X-Spam-Status: No, score=-73.089 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivHjmX+Hp9CW; Fri, 23 May 2008 23:27:36 -0700 (PDT) Received: from 211-108-20-190.adsl.terra.cl (211-108-20-190.adsl.terra.cl [190.20.108.211]) by core3.amsl.com (Postfix) with SMTP id D82FC3A69A2; Fri, 23 May 2008 23:27:20 -0700 (PDT) X-Originating-IP: 201.200.254.248 by smtp.190.20.108.211; Sat, 24 May 2008 02:27:16 -0500 Message-ID: From: "Josue Hayes" Reply-To: "Josue Hayes" To: capwap-archive@megatron.ietf.org Subject: 15% off on two watches Date: Sat, 24 May 2008 02:27:16 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://losykonuzun50.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://losykonuzun50.blogspot.com/ From cabmail@woodenradiatorcabinet.com Mon May 26 00:52:39 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C143A6B48; Mon, 26 May 2008 00:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.222 X-Spam-Level: X-Spam-Status: No, score=-26.222 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXMCZfPjKamY; Mon, 26 May 2008 00:52:33 -0700 (PDT) Received: from cm-85-152-146-209.telecable.es (cm-85-152-146-209.telecable.es [85.152.146.209]) by core3.amsl.com (Postfix) with SMTP id 3F7023A6997; Mon, 26 May 2008 00:52:13 -0700 (PDT) X-Originating-IP: 194.81.121.210 by smtp.85.152.146.209; Mon, 26 May 2008 03:52:27 -0500 Message-ID: From: "Pablo Hammer" Reply-To: "Pablo Hammer" To: atompub-archive@megatron.ietf.org Subject: Watches made to impress Date: Mon, 26 May 2008 03:52:27 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www%2Ejusiile%2Ecom/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www%2Ejusiile%2Ecom/ From c.pasquet@graphosphere.com Mon May 26 05:20:18 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D16A3A6BA7; Mon, 26 May 2008 05:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.284 X-Spam-Level: X-Spam-Status: No, score=-19.284 tagged_above=-999 required=5 tests=[AWL=-1.972, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgHpaJrWynBa; Mon, 26 May 2008 05:20:10 -0700 (PDT) Received: from 190-51-183-219.speedy.com.ar (unknown [190.51.183.219]) by core3.amsl.com (Postfix) with SMTP id E3F043A694B; Mon, 26 May 2008 05:19:58 -0700 (PDT) X-Originating-IP: 15.76.250.164 by smtp.190.51.183.219; Mon, 26 May 2008 08:20:10 -0500 Message-ID: From: "Carissa Crane" Reply-To: "Carissa Crane" To: call-home-bounces@ietf.org Subject: Elegant watches for less than half Date: Mon, 26 May 2008 08:20:10 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://www%2Esuppoenn%2Ecom/ From c.porot@mutualitefrancaiserhone.fr Mon May 26 12:24:19 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEF53A6BDF; Mon, 26 May 2008 12:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.648 X-Spam-Level: X-Spam-Status: No, score=-15.648 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIeu7EVVkrdm; Mon, 26 May 2008 12:24:13 -0700 (PDT) Received: from host51-133-dynamic.7-87-r.retail.telecomitalia.it (host51-133-dynamic.7-87-r.retail.telecomitalia.it [87.7.133.51]) by core3.amsl.com (Postfix) with SMTP id CF31E3A69FC; Mon, 26 May 2008 12:24:02 -0700 (PDT) X-Originating-IP: 194.32.17.48 by smtp.87.7.133.51; Mon, 26 May 2008 15:24:17 -0500 Message-ID: From: "Ronnie Grimm" Reply-To: "Ronnie Grimm" To: atompub-archive@megatron.ietf.org Subject: The affordable watch alternative Date: Mon, 26 May 2008 15:24:17 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080526-0, 26/05/2008), Outbound message X-Antivirus-Status: Clean Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Eadieks%2Ecom/ From ca-ajbm-owner@ajbm.qc.ca Mon May 26 18:34:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9153A6C15; Mon, 26 May 2008 18:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.272 X-Spam-Level: X-Spam-Status: No, score=-15.272 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQV0ItM6sirj; Mon, 26 May 2008 18:34:32 -0700 (PDT) Received: from 190-49-140-230.speedy.com.ar (unknown [190.49.140.230]) by core3.amsl.com (Postfix) with SMTP id 8B5953A6B8F; Mon, 26 May 2008 18:34:21 -0700 (PDT) X-Originating-IP: 160.8.64.134 by smtp.190.49.140.230; Mon, 26 May 2008 21:34:34 -0500 Message-ID: From: "Tommie Babb" Reply-To: "Tommie Babb" To: call-home-bounces@ietf.org Subject: Get 15% off these watches Date: Mon, 26 May 2008 21:34:34 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www%2Emiracuole%2Ecom/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www%2Emiracuole%2Ecom/ From kansas_@datafull.com Mon May 26 21:29:53 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5D33A6C1A for ; Mon, 26 May 2008 21:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.503 X-Spam-Level: ** X-Spam-Status: No, score=2.503 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.692, DNS_FROM_RFC_BOGUSMX=1.482, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuD7eSkGk0jG for ; Mon, 26 May 2008 21:29:52 -0700 (PDT) Received: from avas-mr20.fibertel.com.ar (avas-mr20.fibertel.com.ar [24.232.0.123]) by core3.amsl.com (Postfix) with ESMTP id EFE5B3A6C13 for ; Mon, 26 May 2008 21:29:48 -0700 (PDT) Received: from 176-6-245-190.fibertel.com.ar ([190.245.6.176]:4865 "EHLO desktop" smtp-auth: "directodefabrica" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr20.fibertel.com.ar with ESMTPA id S1019169AbYE0E3R convert rfc822-to-8bit; Tue, 27 May 2008 01:29:17 -0300 Message-ID: <384-22008522742915630@desktop> To: "kansas dvds" Reply-To: "kansas@datafull.com" From: "kansas@datafull.com" Subject: KANSAS DVDs 20 de MAYO Date: Tue, 27 May 2008 06:29:15 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: e7c6d7414b6c274a3897095669d0a72d X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: kansas_@datafull.com KANSAS DVDs kansas@datafull.com DVD con portada color y caja DVD $8 cada uno 10 unidades $7 cada uno 20 unidades $6,5 cada uno 50 unidades $6 cada uno 100 unidades $5 cada uno DVDs en sobre: 10 unidades $5 cada uno 20 unidades $4,25 cada uno 50 unidades $3,5 cada uno 100 unidades $2,5 cada uno 1364 Bee Movie 1365 La Mujer de Mis Pesadillas (con Ben Stiller) 1366 Asesinato de Jeese James 1367 Supercool 1368 El Reino 1369 Ligeramente Embarazada 1370 Resident Evil 3 1371 Susurro de Terror 1372 Licencia para Casarse 1373 El Sospechoso 1374 BeoWulf 1375 El Vidente 1376 El Arca 1377 Justicia a Cualquier Precio 1378 Casper 1379 En Nombre del Odio 1380 Sin Reservas 1381 Mimzy 1382 Juego de Gemelas 1383 Padrinos Magicos: Abra Catastrofe 1384 Baby Einstein: Un dia en la Granja 1385 Dinero de Sangre 1386 Infidelidad y Romance 1387 Acorralados Solicitar lista completa kansas@datafull.com Ante cualquier duda avisame por este medio Saluda atentamente   Daniel Lomas Kansas DVDs kansas@datafull.com From caciara@caciara.it Tue May 27 01:47:57 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C773A6784; Tue, 27 May 2008 01:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.857 X-Spam-Level: X-Spam-Status: No, score=-6.857 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_FR=0.35, HTTP_ESCAPED_HOST=0.134, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2dQy8kDPbVD; Tue, 27 May 2008 01:47:50 -0700 (PDT) Received: from LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr (LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr [193.251.191.146]) by core3.amsl.com (Postfix) with SMTP id 6F14728C218; Tue, 27 May 2008 01:46:35 -0700 (PDT) X-Originating-IP: 112.96.12.238 by smtp.193.251.191.146; Tue, 27 May 2008 04:46:50 -0500 Message-ID: From: "Jonah Mcgee" Reply-To: "Jonah Mcgee" To: atompub-archive@megatron.ietf.org Subject: Why get an original watch? Date: Tue, 27 May 2008 04:46:50 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://www%2Ebybyusse%2Ecom/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://www%2Ebybyusse%2Ecom/ From c40rob@wfbc.com Tue May 27 02:10:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479AA3A67B0; Tue, 27 May 2008 02:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.329 X-Spam-Level: X-Spam-Status: No, score=-11.329 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUdvQIbnw5ZA; Tue, 27 May 2008 02:10:07 -0700 (PDT) Received: from 252-104-20-190.adsl.terra.cl (252-104-20-190.adsl.terra.cl [190.20.104.252]) by core3.amsl.com (Postfix) with SMTP id 27A0C3A68D4; Tue, 27 May 2008 02:09:52 -0700 (PDT) X-Originating-IP: 194.196.0.254 by smtp.190.20.104.252; Tue, 27 May 2008 05:09:57 -0500 Message-ID: From: "Daren Landry" Reply-To: "Daren Landry" To: cancer@ietf.org Subject: Get your watch now Date: Tue, 27 May 2008 05:09:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://www%2Eselissia%2Ecom/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://www%2Eselissia%2Ecom/ From c.millet@pre-sport.com Tue May 27 09:46:31 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044883A6A02; Tue, 27 May 2008 09:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.607 X-Spam-Level: X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[AWL=-2.335, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u3twRyGTJ2r; Tue, 27 May 2008 09:46:24 -0700 (PDT) Received: from 190-51-116-147.speedy.com.ar (unknown [190.51.116.147]) by core3.amsl.com (Postfix) with SMTP id E2DCD3A67DF; Tue, 27 May 2008 09:45:28 -0700 (PDT) X-Originating-IP: 168.193.56.72 by smtp.190.51.116.147; Tue, 27 May 2008 12:45:42 -0500 Message-ID: From: "Dena Schmitz" Reply-To: "Dena Schmitz" To: call-home-bounces@ietf.org Subject: Elegant watches for less than half Date: Tue, 27 May 2008 12:45:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://www%2Eassieyyu%2Ecom/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://www%2Eassieyyu%2Ecom/ From owner-ccamp@ops.ietf.org Tue May 27 11:08:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CBA3A6A31 for ; Tue, 27 May 2008 11:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg4uwRQ7hT1F for ; Tue, 27 May 2008 11:08:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66D4D3A6A69 for ; Tue, 27 May 2008 11:08:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K13TW-000CmT-5Z for ccamp-data@psg.com; Tue, 27 May 2008 18:00:42 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K13Sz-000Cg9-Ru for ccamp@ops.ietf.org; Tue, 27 May 2008 18:00:25 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 35A5B3A6B00; Tue, 27 May 2008 11:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080527180002.35A5B3A6B00@core3.amsl.com> Date: Tue, 27 May 2008 11:00:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 Labels for G.694 Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, H. Guo, K. Miyazaki, D. Caviglia Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt Pages : 10 Date : 2008-5-27 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-27105517.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Tue May 27 14:07:28 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D0B3A6A29 for ; Tue, 27 May 2008 14:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qrm309ngTXI for ; Tue, 27 May 2008 14:07:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80ABC3A6A5F for ; Tue, 27 May 2008 14:07:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K16Hy-000Bwj-8r for ccamp-data@psg.com; Tue, 27 May 2008 21:00:58 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K16HB-000BqU-5c for ccamp@ops.ietf.org; Tue, 27 May 2008 21:00:27 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A7FF53A6826; Tue, 27 May 2008 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080527210001.A7FF53A6826@core3.amsl.com> Date: Tue, 27 May 2008 14:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-rfc4420bis-03.txt Pages : 22 Date : 2008-05-27 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rfc4420bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-27135247.I-D@ietf.org> --NextPart-- From c.moroni@ritoll.com Tue May 27 22:18:59 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5D83A6C4B; Tue, 27 May 2008 22:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXNlN-lUD15q; Tue, 27 May 2008 22:18:59 -0700 (PDT) Received: from cable200-116-0-143.epm.net.co (cable200-116-0-143.epm.net.co [200.116.0.143]) by core3.amsl.com (Postfix) with SMTP id 49A873A6C47; Tue, 27 May 2008 22:18:44 -0700 (PDT) X-Originating-IP: 98.220.30.179 by smtp.200.116.0.143; Wed, 28 May 2008 01:18:59 -0500 Message-ID: From: "Oscar Bryant" Reply-To: "Oscar Bryant" To: call-home-bounces@ietf.org Subject: Take a look at the latest replica watches Date: Wed, 28 May 2008 01:18:59 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080527-1, 27/05/2008), Outbound message X-Antivirus-Status: Clean If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://www%2Enunubsyy%2Ecom/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://www%2Enunubsyy%2Ecom/ From owner-ccamp@ops.ietf.org Wed May 28 02:08:12 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463CD3A69F3 for ; Wed, 28 May 2008 02:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03ZKQ+aczuoG for ; Wed, 28 May 2008 02:08:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 072DF3A6C8A for ; Wed, 28 May 2008 02:08:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1HWT-000Fg3-ML for ccamp-data@psg.com; Wed, 28 May 2008 09:00:41 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1HVy-000Fci-UO for ccamp@ops.ietf.org; Wed, 28 May 2008 09:00:26 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 0CA1F3A6C9F; Wed, 28 May 2008 02:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-reqs-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080528090002.0CA1F3A6C9F@core3.amsl.com> Date: Wed, 28 May 2008 02:00:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-gmpls-mln-reqs-11.txt Pages : 27 Date : 2008-05-28 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. Expires November 2008 [page 1] draft-ietf-ccamp-gmpls-mln-reqs-11.txt May 2008 In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-28014703.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Thu May 29 01:36:52 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C873A6A01 for ; Thu, 29 May 2008 01:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uroRfLUVqaYC for ; Thu, 29 May 2008 01:36:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BDBA3A6941 for ; Thu, 29 May 2008 01:36:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1dRW-000AAa-Pj for ccamp-data@psg.com; Thu, 29 May 2008 08:25:02 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1dQi-000A2a-Kw for ccamp@ops.ietf.org; Thu, 29 May 2008 08:24:29 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4T8O8qn005340 for ; Thu, 29 May 2008 09:24:10 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4T8O6e9005323 for ; Thu, 29 May 2008 09:24:08 +0100 Message-ID: <06cc01c8c165$5b4a1ae0$9001010a@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Internal WG Review: Recharter of Common Control and Measurement Plane (ccamp) Date: Thu, 29 May 2008 09:24:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, FYI. Adrian ----- Original Message ----- From: "IESG Secretary" To: ; ; ; Sent: Thursday, May 29, 2008 2:45 AM Subject: Internal WG Review: Recharter of Common Control and Measurement Plane (ccamp) >A new charter for the Common Control and Measurement Plane Working Group > (ccamp) in the Routing Area of the IETF is being considered. The draft > charter is provided below for your review and comment. > > Specifically, we would like to add the following text as the last bullet > item in the list of bullets in the "Description of working group" > section under "CCAMP WG currently works on the following tasks": > > - Include extensions to the CCAMP WG protocols and > RFCs necessary to create an MPLS Transport Profile (MPLS TP). > The work on the MPLS TP will be coordinated between the > three working groups (MPLS, PWE3 and CCAMP) that are chartered > to do MPLS TP work. > > Also please update the last sentence in the description of working group > section as follows: > > Old: In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. > > New: In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN, PCE, and PWE3. > > Review time is one week. > > The IETF Secretariat > > Common Control and Measurement Plane (ccamp) > -------------------------------------------- > > Last Modified: 2008-05-28 > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > Deborah Brungard > > Routing Area Director(s): > Ross Callon > David Ward > > Routing Area Advisor: > Ross Callon > > Technical Advisor(s): > Lou Berger > > Mailing Lists: > General Discussion: ccamp@ops.ietf.org > To Subscribe: majordomo@ops.ietf.org > In Body: subscribe ccamp > Archive: https://ops.ietf.org/lists/ccamp > > > Description of Working Group: > > Organizational Overview > > The CCAMP working group coordinates the work within the IETF > defining a common control plane and a separate common measurement > plane for physical path and core tunneling technologies of Internet > and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O > optical switches, TDM Switches, Ethernet Switches, ATM and Frame > Relay switches, IP encapsulation tunneling technologies, and MPLS > in cooperation with the MPLS WG. > > In this context, measurement refers to the acquisition and > distribution of attributes relevant to the setting up of tunnels > and paths. > > CCAMP WG work scope includes: > > - Definition of protocol-independent metrics and parameters > (measurement attributes) for describing links and paths that are > required for routing and signaling. These will be developed in > conjunction with requests and requirements from other WGs to > ensure overall usefulness. > > - Definition of protocol(s) and extensions to them required for > link and path attribute measurement. Link Management Protocol > (LMP) is included here. > > - Functional specification of extensions for routing (OSPF, ISIS) > and signalling (RSVP-TE) required for path establishment. > Protocol formats and procedures that embody these extensions will > be done jointly with the WGs supervising those protocols. > > - Definition of the mechanisms required to determine the route and > properties of an established path (tunnel tracing). > > - Definition of MIB modules and other OAM techniques relevant to > the protocols and extensions specified within the WG. > > - Work on traffic-engineering GMPLS mechanisms and protocol > extensions to support source-controlled and explicitly-routed > Ethernet data paths for Ethernet data planes that are already > approved by an SDO with responsibility for the Ethernet data > plane. It is expected that the primary SDO in this case is the > IEEE. Note that the specification or modification of Ethernet > data planes is out of scope. > > CCAMP WG currently works on the following tasks: > > - Define how the properties of network resources gathered by a > measurement protocol can be distributed in existing routing > protocols, such as OSPF and IS-IS. CCAMP defines the generic > description of the properties and how they are distributed in > OSPF. The specifics of distribution within IS-IS are being > addressed in the ISIS WG. > > - Define signaling and routing mechanisms and extensions to allow > path and tunnel setup and maintenance across multiple domains, > where a domain may be an IGP area, an Autonomous System, or any > other region of topological visibility. To this end, work > cooperatively with the PCE and MPLS WGs. > > - Define abstract link and path properties needed for link and > path protection. Specify signalling mechanisms for path > protection, diverse routing and fast path restoration. Ensure > that multi-layer path protection and restoration functions are > achievable using the defined signalling, routing, and measurement > protocols, either separately or in combination. > > - Identify which requirements for signaling and routing for ASON > are not currently met by protocols defined in CCAMP; based on > these, define mechanisms to address these requirements. > > - Document issues and strategies for the migration of MPLS-based > deployments to GMPLS. Based on the outcome, identify protocol > machinery that implementations may have to change to ease the > migration from MPLS to GMPLS. > > - Include extensions to the CCAMP WG protocols and > RFCs necessary to create an MPLS Transport Profile (MPLS TP). > The work on the MPLS TP will be coordinated between the > three working groups (MPLS, PWE3 and CCAMP) that are chartered > to do MPLS TP work. > > In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN, PCE, and PWE3. The > WG will also cooperate with the ITU-T and the IEEE 802.1. > > Goals and Milestones: > > Done Post strawman WG goals and charter > > Done Identify and document a limited set of candidate solutions for > signalling and for measurement. Among candidate control solutions to be > considered are the existing GMPLS drafts. > > Done Build appropriate design teams > > Done Submit WG document defining path setup portions of common > control plane protocol > > Done Submit WG document defining common measurement plane protocol > > Done Submit LMP MIB to IESG > > Done Submit protection & restoration documents to IESG > > Done Submit ASON signaling requirements doc to IESG > > Done Submit GMPLS MIBs to IESG > > Done Produce CCAMP WG document for generic tunnel tracing protocol > > Done Produce CCAMP WG document for multi-area/AS signaling and > routing > > Done Submit ASON routing requirements doc to IESG > > Done Submit revised charter and milestones to IESG for IESG > consideration of more detailed deliverables and determination of > usefulness of continuation of WG > > Done First version WG I-D for Advertising TE Node Capabilities in > ISIS and OSPF > > Done First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > > Done Submit ASON Routing evaluation I-D for IESG review > > Done Cross-WG review of I-D for Advertising TE Node Capabilities in > ISIS and OSPF > > Done First version WG I-D MPLS to GMPLS migration strategies > > Done First version WG I-D Requirements for Multi-Layer and > Multi-Region Networks > > Done First version WG I-D for Evaluation of existing protocols for > MLN/MRN > > Done First version of WG I-D for ASON Routing solutions > > Done Submit RSVP-TE extensions for inter-domain signaling I-D for > IESG review > > Done Submit Per-domain path computation signaling I-D for IESG review > > > Done First version of WG I-D for OSPF-TE/GMPLS MIB module > > Done Submit GMPLS signaling in support of Call Management I-D for > IESG review > > Done First version WG Informational I-D for Analysis of inter-domain > issues for disjoint and protected paths > > Done Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF > for IESG review > > Done First version WG I-D for Protocol solutions for MLN/MRN > > Done Submit GMPLS/ASON lexicography I-D for IESG review > > Done First version WG I-D MPLS-GMPLS interworking requirements and > solutions > > Done Submit LSP Stitching I-D for IESG review > > Done Submit I-D for Automatic discovery of MPLS-TE mesh membership > for IESG review > > Done First version WG I-D GMPLS OAM Requirements > > Done Submit GMPLS routing and signaling interoperability advice I-D > for IESG review > > Done Submit MPLS to GMPLS migration strategies I-D for IESG review > > Done Submit Requirements for Multi-Layer and Multi-Region Networks > I-D for IESG review > > Done Submit MPLS-GMPLS interworking requirements and solutions I-D > for IESG review > > Done Submit Evaluation of existing protocols for MLN/MRN for IESG > review > > Feb 2007 First version of WG I-D for additional MIB module to cover > RSVP-TE signaling extensions > > Done First version WG I-Ds for GMPLS source-controlled and > explicitly-routed Ethernet networks > > Done Submit Informational I-D for Analysis of inter-domain issues for > disjoint and protected paths for IESG review > > Jan 2008 Submit ASON Routing solutions I-D for IESG review > > Feb 2008 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG > review > > Feb 2008 Submit GMPLS OAM Requirements I-D for IESG review > > Mar 2008 Submit Protocol solutions for MLN/MRN I-D for IESG review > > May 2008 Submit MIB module for RSVP-TE signaling extensions for MIB > doctor and IESG review > > Sep 2008 Submit protocol extensions for GMPLS source-controlled and > explicitly-routed Ethernet networks for IESG review > > Jan 2009 Recharter or close Working Group > From owner-ccamp@ops.ietf.org Thu May 29 11:35:37 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5523A6A31 for ; Thu, 29 May 2008 11:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbInFQxDJEsc for ; Thu, 29 May 2008 11:35:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFF4E3A6AF2 for ; Thu, 29 May 2008 11:33:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1mjM-0008Tg-EF for ccamp-data@psg.com; Thu, 29 May 2008 18:20:04 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1miu-0008PN-6f for ccamp@ops.ietf.org; Thu, 29 May 2008 18:19:49 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 00AEA3A6BCF; Thu, 29 May 2008 11:16:25 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)' to Informational RFC Message-Id: <20080529181626.00AEA3A6BCF@core3.amsl.com> Date: Thu, 29 May 2008 11:16:25 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-11.txt Technical Summary Generalized MPLS (GMPLS) extends MPLS to handle multiple switching technologies: packet switching, layer-2 switching, TDM switching, wavelength switching, and fiber switching (see [RFC3945]). The Interface Switching Capability (ISC) concept is introduced to describe these diverse switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. Working Group Summary No controversy reported. Support for multi-region and multi-layer networks is natural given the GMPLS capabilities that CCAMP has been working on for some time. Document Quality Since this document defines a framework and requirements only, it is not something that would be implemented directly. It has been reviewed broadly both within the CCAMP working group and ITU-T (see a bit more detail in the PROTO writeup by Adrian Farrel). Personnel Adrian Farrel is the PROTO shepherd. Ross Callon is the Responsible Area Director? There are no IANA requirements for this document. From owner-ccamp@ops.ietf.org Thu May 29 13:28:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6DBD3A69E2 for ; Thu, 29 May 2008 13:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.546 X-Spam-Level: X-Spam-Status: No, score=-105.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlTrWnK3o-KP for ; Thu, 29 May 2008 13:28:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AFF53A685C for ; Thu, 29 May 2008 13:28:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1odG-000NU9-5T for ccamp-data@psg.com; Thu, 29 May 2008 20:21:54 +0000 Received: from [216.82.245.115] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1ocl-000NPR-Fa for ccamp@ops.ietf.org; Thu, 29 May 2008 20:21:39 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1212092478!20812591!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 10729 invoked from network); 29 May 2008 20:21:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 29 May 2008 20:21:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4TKLHOB027384; Thu, 29 May 2008 16:21:18 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m4TKL9WJ027236; Thu, 29 May 2008 16:21:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C1C9.87DC6B38" Subject: Please publish draft-ietf-ccamp-rfc4420bis-03.txt Date: Thu, 29 May 2008 16:21:08 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-rfc4420bis-03.txt Thread-Index: AcjByYdosCQ0pHZSTkqaNq0MGicw+Q== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , "David Ward" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C1C9.87DC6B38 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-rfc4420bis-03.txt Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Deborah Brungard is the document shepherd. She has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D had good review and discussion in the CCAMP working group doing its development. The discrepency in RFC 4420 addressed by this document was identified by a forum during interoperability testing and communicated to CCAMP. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No concerns. No IPR disclosures have been filed. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downward references. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The IANA allocations made for RFC 4420 apply to this document. No new IANA allocations are needed. In Section 11 "IANA Considerations", it is requested for IANA to update RFC 4420 registry entries to reference this document. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. This document replaces and obsoletes the previous version of this work published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. > Working Group Summary=20 > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG had good consensus with no disputes or disagreements. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There are a substantial number of implementations. Interoperability testing by a forum identified the discrepency in RFC 4420 which is addressed by this document. ------_=_NextPart_001_01C8C1C9.87DC6B38 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Proto-write-up for draft-ietf-ccamp-rfc4420bis-03.txt

Intended status : Standards Track

> (1.a) Who is the Document Shepherd = for this=20 document? Has the

> Document Shepherd personally = reviewed this=20 version of the

> document and, in particular, does he = or she=20 believe this

> version is ready for forwarding to = the IESG for=20 publication?

Deborah=20 Brungard is the document shepherd.

She has=20 personally reviewed the I-D and believes it is ready = for

forwarding to the IESG for = publication.

> (1.b) Has the document had adequate = review both=20 from key WG members

> and from key non-WG members? Does = the Document=20 Shepherd have

> any concerns about the depth or = breadth of the=20 reviews that

> have been performed?

I-D had good review and discussion in the CCAMP working

group doing its=20 development. The discrepency in = RFC 4420=20 addressed by this

document was identified by a forum during=20 interoperability testing and

communicated to = CCAMP.

> (1.c) Does the Document Shepherd = have concerns=20 that the document

> needs more review from a particular = or broader=20 perspective,

> e.g., security, operational = complexity, someone=20 familiar with

> AAA, internationalization or = XML?

No concerns.

> (1.d) Does the Document Shepherd = have any=20 specific concerns or

> issues with this document that the = Responsible=20 Area Director

> and/or the IESG should be aware of? = For example,=20 perhaps he

> or she is uncomfortable with certain = parts of=20 the document, or

> has concerns whether there really is = a need for=20 it. In any

> event, if the WG has discussed those = issues and=20 has indicated

> that it still wishes to advance the = document,=20 detail those

> concerns here. Has an IPR disclosure = related to=20 this document

> been filed? If so, please include a = reference to=20 the

> disclosure and summarize the WG = discussion and=20 conclusion on

> this issue.

No = concerns. No IPR=20 disclosures have been filed.

> (1.e) How solid is the WG consensus = behind this=20 document? Does it

> represent the strong concurrence of = a few=20 individuals, with

> others being silent, or does the WG = as a whole=20 understand and

> agree with it?

Consensus is good.

> (1.f) Has anyone threatened an = appeal or=20 otherwise indicated extreme

> discontent? If so, please summarise = the areas of=20 conflict in

> separate email messages to the = Responsible Area=20 Director. (It

> should be in a separate email = because this=20 questionnaire is

> entered into the ID = Tracker.)

No threats. No discontent.

> (1.g) Has the Document Shepherd = personally=20 verified that the

> document satisfies all ID nits? = (See

> http://www.ietf.org/ID-Checklist.html and

> http://tools.ietf.org/tools/idnits/). Boilerplate checks are

> not enough; this check needs to be = thorough. Has=20 the document

> met all formal review criteria it = needs to, such=20 as the MIB

> Doctor, media type and URI type=20 reviews?

All checks made.

> (1.h) Has the document split its = references into=20 normative and

> informative? Are there normative = references to=20 documents that

> are not ready for advancement or are = otherwise=20 in an unclear

> state? If such normative references = exist, what=20 is the

> strategy for their completion? Are = there=20 normative references

> that are downward references, as = described in=20 [RFC3967]? If

> so, list these downward references = to support=20 the Area

> Director in the Last Call procedure = for them=20 [RFC3967].

References split. No downward = references.

> (1.i) Has the Document Shepherd = verified that=20 the document IANA

> consideration section exists and is = consistent=20 with the body

> of the document? If the document = specifies=20 protocol

> extensions, are reservations = requested in=20 appropriate IANA

> registries? Are the IANA registries = clearly=20 identified? If

> the document creates a new registry, = does it=20 define the

> proposed initial contents of the = registry and an=20 allocation

> procedure for future registrations? = Does it=20 suggest a

> reasonable name for the new = registry? See=20 [RFC2434]. If the

> document describes an Expert Review = process has=20 Shepherd

> conferred with the Responsible Area = Director so=20 that the IESG

> can appoint the needed Expert during = the IESG=20 Evaluation?

The IANA = allocations=20 made for RFC 4420 apply to this document.

No new = IANA=20 allocations are needed. In Section 11 "IANA = Considerations",

it is = requested=20 for IANA to update RFC 4420 registry entries = to

reference this=20 document.

> (1.j) Has the Document Shepherd = verified that=20 sections of the

> document that are written in a = formal language,=20 such as XML

> code, BNF rules, MIB definitions, = etc., validate=20 correctly in

> an automated checker?

No such formal language is = used.

> (1.k) The IESG approval announcement = includes a=20 Document

> Announcement Write-Up. Please = provide such a=20 Document

> Announcement Write-Up. Recent = examples can be=20 found in the

> "Action" announcements for approved = documents.=20 The approval

> announcement contains the following=20 sections:

>

> Technical Summary

> Relevant content can frequently be = found in the=20 abstract

> and/or introduction of the document. = If not,=20 this may be

> an indication that there are = deficiencies in the=20 abstract

> or introduction.

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) = may be

established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE)

extensions.  This protocol includes an object (the SESSION_ATTRIBUTE object) = that

carries a Flags field used to = indicate=20 options and attributes of the LSP.  That Flags field

has eight bits allowing for = eight=20 options to be set.  Recent proposals in=20 many documents that

extend RSVP-TE have suggested uses for each of=20 the previously unused bits.

This document defines a new = object for=20 RSVP-TE messages that allows the = signaling=20 of further

attribute bits and also the carriage of=20 arbitrary attribute parameters to make RSVP-TE easily

extensible to support new=20 requirements.  Additionally, this document defines a way

to record the attributes applied to the LSP on a hop-by-hop = basis.

The=20 object mechanisms defined in this document are equally = applicable to=20 Generalized MPLS

(GMPLS) Packet Switch Capable (PSC) = LSPs and=20 to GMPLS non-PSC LSPs.

This document replaces and obsoletes the = previous=20 version of this work published as RFC 4420.

The only change is in the encoding = of the=20 Type-Length-Variable (TLV) data structures.

>=20 Working Group Summary=20

> Was there anything in WG process = that is worth=20 noting? For

> example, was there controversy about = particular=20 points or

> were there decisions where the = consensus was=20 particularly

> rough?

WG had good=20 consensus with no disputes or disagreements.

> Document Quality

> Are there existing implementations = of the=20 protocol? Have a

> significant number of vendors = indicated their=20 plan to

> implement the specification? Are = there any=20 reviewers that

> merit special mention as having done = a thorough=20 review,

> e.g., one that resulted in important = changes or=20 a

> conclusion that the document had no = substantive=20 issues? If

> there was a MIB Doctor, Media Type = or other=20 expert review,

> what was its course (briefly)? In = the case of a=20 Media Type

> review, on what date was the request = posted?

There are a substantial number of = implementations.=20 Interoperability testing

by a forum identified the discrepency in RFC = 4420 which=20 is addressed by this

document.

------_=_NextPart_001_01C8C1C9.87DC6B38-- From owner-ccamp@ops.ietf.org Thu May 29 14:22:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480C03A68BC for ; Thu, 29 May 2008 14:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmaCQrNJVP-p for ; Thu, 29 May 2008 14:22:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7972D28C17D for ; Thu, 29 May 2008 14:22:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1pTB-0003MS-9k for ccamp-data@psg.com; Thu, 29 May 2008 21:15:33 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1pSh-0003J1-4F for ccamp@ops.ietf.org; Thu, 29 May 2008 21:15:17 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 4287A3A6B24; Thu, 29 May 2008 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080529211502.4287A3A6B24@core3.amsl.com> Date: Thu, 29 May 2008 14:15:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 Labels for G.694 Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, H. Guo, K. Miyazaki, D. Caviglia Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt Pages : 10 Date : 2008-5-29 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-29140142.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Sat May 31 08:13:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0440C3A6911 for ; Sat, 31 May 2008 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.476 X-Spam-Level: X-Spam-Status: No, score=-100.476 tagged_above=-999 required=5 tests=[AWL=-2.124, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgR4OoojzC3L for ; Sat, 31 May 2008 08:13:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6FE83A686E for ; Sat, 31 May 2008 08:13:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K2Scm-000KnO-MQ for ccamp-data@psg.com; Sat, 31 May 2008 15:04:04 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K2Sc9-000Kig-Sp for ccamp@ops.ietf.org; Sat, 31 May 2008 15:03:43 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm448418225; Sat, 31 May 2008 23:18:07 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm34483cc630; Wed, 28 May 2008 05:17:34 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 28 May 2008 05:17:34 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7542D3A694F; Tue, 27 May 2008 14:00:04 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A7FF53A6826; Tue, 27 May 2008 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080527210001.A7FF53A6826@core3.amsl.com> Date: Tue, 27 May 2008 14:00:01 -0700 (PDT) Cc: ccamp@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-rfc4420bis-03.txt Pages : 22 Date : 2008-05-27 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rfc4420bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-27135247.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 31 May 2008 15:07:14 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080527210001.A7FF53A6826@core3.amsl.com> Date: Tue, 27 May 2008 14:00:01 -0700 (PDT) Cc: ccamp@ops.ietf.org Reply-To: internet-drafts@ietf.org --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 : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-rfc4420bis-03.txt Pages : 22 Date : 2008-05-27 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rfc4420bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-27135247.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 May 2008 21:16:49 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080529211502.4287A3A6B24@core3.amsl.com> Date: Thu, 29 May 2008 14:15:02 -0700 (PDT) --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 Labels for G.694 Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, H. Guo, K. Miyazaki, D. Caviglia Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt Pages : 10 Date : 2008-5-29 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-29140142.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 May 2008 20:23:04 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C1C9.87DC6B38" Subject: Please publish draft-ietf-ccamp-rfc4420bis-03.txt Date: Thu, 29 May 2008 16:21:08 -0400 Message-ID: Thread-Topic: Please publish draft-ietf-ccamp-rfc4420bis-03.txt Thread-Index: AcjByYdosCQ0pHZSTkqaNq0MGicw+Q== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , "David Ward" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C1C9.87DC6B38 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-rfc4420bis-03.txt Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Deborah Brungard is the document shepherd. She has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D had good review and discussion in the CCAMP working group doing its development. The discrepency in RFC 4420 addressed by this document was identified by a forum during interoperability testing and communicated to CCAMP. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No concerns. No IPR disclosures have been filed. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downward references. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The IANA allocations made for RFC 4420 apply to this document. No new IANA allocations are needed. In Section 11 "IANA Considerations", it is requested for IANA to update RFC 4420 registry entries to reference this document. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. This document replaces and obsoletes the previous version of this work published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. > Working Group Summary=20 > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG had good consensus with no disputes or disagreements. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There are a substantial number of implementations. Interoperability testing by a forum identified the discrepency in RFC 4420 which is addressed by this document. ------_=_NextPart_001_01C8C1C9.87DC6B38 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Proto-write-up for draft-ietf-ccamp-rfc4420bis-03.txt

Intended status : Standards Track

> (1.a) Who is the Document Shepherd = for this=20 document? Has the

> Document Shepherd personally = reviewed this=20 version of the

> document and, in particular, does he = or she=20 believe this

> version is ready for forwarding to = the IESG for=20 publication?

Deborah=20 Brungard is the document shepherd.

She has=20 personally reviewed the I-D and believes it is ready = for

forwarding to the IESG for = publication.

> (1.b) Has the document had adequate = review both=20 from key WG members

> and from key non-WG members? Does = the Document=20 Shepherd have

> any concerns about the depth or = breadth of the=20 reviews that

> have been performed?

I-D had good review and discussion in the CCAMP working

group doing its=20 development. The discrepency in = RFC 4420=20 addressed by this

document was identified by a forum during=20 interoperability testing and

communicated to = CCAMP.

> (1.c) Does the Document Shepherd = have concerns=20 that the document

> needs more review from a particular = or broader=20 perspective,

> e.g., security, operational = complexity, someone=20 familiar with

> AAA, internationalization or = XML?

No concerns.

> (1.d) Does the Document Shepherd = have any=20 specific concerns or

> issues with this document that the = Responsible=20 Area Director

> and/or the IESG should be aware of? = For example,=20 perhaps he

> or she is uncomfortable with certain = parts of=20 the document, or

> has concerns whether there really is = a need for=20 it. In any

> event, if the WG has discussed those = issues and=20 has indicated

> that it still wishes to advance the = document,=20 detail those

> concerns here. Has an IPR disclosure = related to=20 this document

> been filed? If so, please include a = reference to=20 the

> disclosure and summarize the WG = discussion and=20 conclusion on

> this issue.

No = concerns. No IPR=20 disclosures have been filed.

> (1.e) How solid is the WG consensus = behind this=20 document? Does it

> represent the strong concurrence of = a few=20 individuals, with

> others being silent, or does the WG = as a whole=20 understand and

> agree with it?

Consensus is good.

> (1.f) Has anyone threatened an = appeal or=20 otherwise indicated extreme

> discontent? If so, please summarise = the areas of=20 conflict in

> separate email messages to the = Responsible Area=20 Director. (It

> should be in a separate email = because this=20 questionnaire is

> entered into the ID = Tracker.)

No threats. No discontent.

> (1.g) Has the Document Shepherd = personally=20 verified that the

> document satisfies all ID nits? = (See

> http://www.ietf.org/ID-Checklist.html and

> http://tools.ietf.org/tools/idnits/). Boilerplate checks are

> not enough; this check needs to be = thorough. Has=20 the document

> met all formal review criteria it = needs to, such=20 as the MIB

> Doctor, media type and URI type=20 reviews?

All checks made.

> (1.h) Has the document split its = references into=20 normative and

> informative? Are there normative = references to=20 documents that

> are not ready for advancement or are = otherwise=20 in an unclear

> state? If such normative references = exist, what=20 is the

> strategy for their completion? Are = there=20 normative references

> that are downward references, as = described in=20 [RFC3967]? If

> so, list these downward references = to support=20 the Area

> Director in the Last Call procedure = for them=20 [RFC3967].

References split. No downward = references.

> (1.i) Has the Document Shepherd = verified that=20 the document IANA

> consideration section exists and is = consistent=20 with the body

> of the document? If the document = specifies=20 protocol

> extensions, are reservations = requested in=20 appropriate IANA

> registries? Are the IANA registries = clearly=20 identified? If

> the document creates a new registry, = does it=20 define the

> proposed initial contents of the = registry and an=20 allocation

> procedure for future registrations? = Does it=20 suggest a

> reasonable name for the new = registry? See=20 [RFC2434]. If the

> document describes an Expert Review = process has=20 Shepherd

> conferred with the Responsible Area = Director so=20 that the IESG

> can appoint the needed Expert during = the IESG=20 Evaluation?

The IANA = allocations=20 made for RFC 4420 apply to this document.

No new = IANA=20 allocations are needed. In Section 11 "IANA = Considerations",

it is = requested=20 for IANA to update RFC 4420 registry entries = to

reference this=20 document.

> (1.j) Has the Document Shepherd = verified that=20 sections of the

> document that are written in a = formal language,=20 such as XML

> code, BNF rules, MIB definitions, = etc., validate=20 correctly in

> an automated checker?

No such formal language is = used.

> (1.k) The IESG approval announcement = includes a=20 Document

> Announcement Write-Up. Please = provide such a=20 Document

> Announcement Write-Up. Recent = examples can be=20 found in the

> "Action" announcements for approved = documents.=20 The approval

> announcement contains the following=20 sections:

>

> Technical Summary

> Relevant content can frequently be = found in the=20 abstract

> and/or introduction of the document. = If not,=20 this may be

> an indication that there are = deficiencies in the=20 abstract

> or introduction.

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) = may be

established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE)

extensions.  This protocol includes an object (the SESSION_ATTRIBUTE object) = that

carries a Flags field used to = indicate=20 options and attributes of the LSP.  That Flags field

has eight bits allowing for = eight=20 options to be set.  Recent proposals in=20 many documents that

extend RSVP-TE have suggested uses for each of=20 the previously unused bits.

This document defines a new = object for=20 RSVP-TE messages that allows the = signaling=20 of further

attribute bits and also the carriage of=20 arbitrary attribute parameters to make RSVP-TE easily

extensible to support new=20 requirements.  Additionally, this document defines a way

to record the attributes applied to the LSP on a hop-by-hop = basis.

The=20 object mechanisms defined in this document are equally = applicable to=20 Generalized MPLS

(GMPLS) Packet Switch Capable (PSC) = LSPs and=20 to GMPLS non-PSC LSPs.

This document replaces and obsoletes the = previous=20 version of this work published as RFC 4420.

The only change is in the encoding = of the=20 Type-Length-Variable (TLV) data structures.

>=20 Working Group Summary=20

> Was there anything in WG process = that is worth=20 noting? For

> example, was there controversy about = particular=20 points or

> were there decisions where the = consensus was=20 particularly

> rough?

WG had good=20 consensus with no disputes or disagreements.

> Document Quality

> Are there existing implementations = of the=20 protocol? Have a

> significant number of vendors = indicated their=20 plan to

> implement the specification? Are = there any=20 reviewers that

> merit special mention as having done = a thorough=20 review,

> e.g., one that resulted in important = changes or=20 a

> conclusion that the document had no = substantive=20 issues? If

> there was a MIB Doctor, Media Type = or other=20 expert review,

> what was its course (briefly)? In = the case of a=20 Media Type

> review, on what date was the request = posted?

There are a substantial number of = implementations.=20 Interoperability testing

by a forum identified the discrepency in RFC = 4420 which=20 is addressed by this

document.

------_=_NextPart_001_01C8C1C9.87DC6B38-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 May 2008 18:22:04 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)' to Informational RFC Message-Id: <20080529181626.00AEA3A6BCF@core3.amsl.com> Date: Thu, 29 May 2008 11:16:25 -0700 (PDT) The IESG has approved the following document: - 'Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-11.txt Technical Summary Generalized MPLS (GMPLS) extends MPLS to handle multiple switching technologies: packet switching, layer-2 switching, TDM switching, wavelength switching, and fiber switching (see [RFC3945]). The Interface Switching Capability (ISC) concept is introduced to describe these diverse switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. Working Group Summary No controversy reported. Support for multi-region and multi-layer networks is natural given the GMPLS capabilities that CCAMP has been working on for some time. Document Quality Since this document defines a framework and requirements only, it is not something that would be implemented directly. It has been reviewed broadly both within the CCAMP working group and ITU-T (see a bit more detail in the PROTO writeup by Adrian Farrel). Personnel Adrian Farrel is the PROTO shepherd. Ross Callon is the Responsible Area Director? There are no IANA requirements for this document. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 May 2008 08:27:53 +0000 Message-ID: <06cc01c8c165$5b4a1ae0$9001010a@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Internal WG Review: Recharter of Common Control and Measurement Plane (ccamp) Date: Thu, 29 May 2008 09:24:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, FYI. Adrian ----- Original Message ----- From: "IESG Secretary" To: ; ; ; Sent: Thursday, May 29, 2008 2:45 AM Subject: Internal WG Review: Recharter of Common Control and Measurement Plane (ccamp) >A new charter for the Common Control and Measurement Plane Working Group > (ccamp) in the Routing Area of the IETF is being considered. The draft > charter is provided below for your review and comment. > > Specifically, we would like to add the following text as the last bullet > item in the list of bullets in the "Description of working group" > section under "CCAMP WG currently works on the following tasks": > > - Include extensions to the CCAMP WG protocols and > RFCs necessary to create an MPLS Transport Profile (MPLS TP). > The work on the MPLS TP will be coordinated between the > three working groups (MPLS, PWE3 and CCAMP) that are chartered > to do MPLS TP work. > > Also please update the last sentence in the description of working group > section as follows: > > Old: In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. > > New: In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN, PCE, and PWE3. > > Review time is one week. > > The IETF Secretariat > > Common Control and Measurement Plane (ccamp) > -------------------------------------------- > > Last Modified: 2008-05-28 > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > Deborah Brungard > > Routing Area Director(s): > Ross Callon > David Ward > > Routing Area Advisor: > Ross Callon > > Technical Advisor(s): > Lou Berger > > Mailing Lists: > General Discussion: ccamp@ops.ietf.org > To Subscribe: majordomo@ops.ietf.org > In Body: subscribe ccamp > Archive: https://ops.ietf.org/lists/ccamp > > > Description of Working Group: > > Organizational Overview > > The CCAMP working group coordinates the work within the IETF > defining a common control plane and a separate common measurement > plane for physical path and core tunneling technologies of Internet > and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O > optical switches, TDM Switches, Ethernet Switches, ATM and Frame > Relay switches, IP encapsulation tunneling technologies, and MPLS > in cooperation with the MPLS WG. > > In this context, measurement refers to the acquisition and > distribution of attributes relevant to the setting up of tunnels > and paths. > > CCAMP WG work scope includes: > > - Definition of protocol-independent metrics and parameters > (measurement attributes) for describing links and paths that are > required for routing and signaling. These will be developed in > conjunction with requests and requirements from other WGs to > ensure overall usefulness. > > - Definition of protocol(s) and extensions to them required for > link and path attribute measurement. Link Management Protocol > (LMP) is included here. > > - Functional specification of extensions for routing (OSPF, ISIS) > and signalling (RSVP-TE) required for path establishment. > Protocol formats and procedures that embody these extensions will > be done jointly with the WGs supervising those protocols. > > - Definition of the mechanisms required to determine the route and > properties of an established path (tunnel tracing). > > - Definition of MIB modules and other OAM techniques relevant to > the protocols and extensions specified within the WG. > > - Work on traffic-engineering GMPLS mechanisms and protocol > extensions to support source-controlled and explicitly-routed > Ethernet data paths for Ethernet data planes that are already > approved by an SDO with responsibility for the Ethernet data > plane. It is expected that the primary SDO in this case is the > IEEE. Note that the specification or modification of Ethernet > data planes is out of scope. > > CCAMP WG currently works on the following tasks: > > - Define how the properties of network resources gathered by a > measurement protocol can be distributed in existing routing > protocols, such as OSPF and IS-IS. CCAMP defines the generic > description of the properties and how they are distributed in > OSPF. The specifics of distribution within IS-IS are being > addressed in the ISIS WG. > > - Define signaling and routing mechanisms and extensions to allow > path and tunnel setup and maintenance across multiple domains, > where a domain may be an IGP area, an Autonomous System, or any > other region of topological visibility. To this end, work > cooperatively with the PCE and MPLS WGs. > > - Define abstract link and path properties needed for link and > path protection. Specify signalling mechanisms for path > protection, diverse routing and fast path restoration. Ensure > that multi-layer path protection and restoration functions are > achievable using the defined signalling, routing, and measurement > protocols, either separately or in combination. > > - Identify which requirements for signaling and routing for ASON > are not currently met by protocols defined in CCAMP; based on > these, define mechanisms to address these requirements. > > - Document issues and strategies for the migration of MPLS-based > deployments to GMPLS. Based on the outcome, identify protocol > machinery that implementations may have to change to ease the > migration from MPLS to GMPLS. > > - Include extensions to the CCAMP WG protocols and > RFCs necessary to create an MPLS Transport Profile (MPLS TP). > The work on the MPLS TP will be coordinated between the > three working groups (MPLS, PWE3 and CCAMP) that are chartered > to do MPLS TP work. > > In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN, PCE, and PWE3. The > WG will also cooperate with the ITU-T and the IEEE 802.1. > > Goals and Milestones: > > Done Post strawman WG goals and charter > > Done Identify and document a limited set of candidate solutions for > signalling and for measurement. Among candidate control solutions to be > considered are the existing GMPLS drafts. > > Done Build appropriate design teams > > Done Submit WG document defining path setup portions of common > control plane protocol > > Done Submit WG document defining common measurement plane protocol > > Done Submit LMP MIB to IESG > > Done Submit protection & restoration documents to IESG > > Done Submit ASON signaling requirements doc to IESG > > Done Submit GMPLS MIBs to IESG > > Done Produce CCAMP WG document for generic tunnel tracing protocol > > Done Produce CCAMP WG document for multi-area/AS signaling and > routing > > Done Submit ASON routing requirements doc to IESG > > Done Submit revised charter and milestones to IESG for IESG > consideration of more detailed deliverables and determination of > usefulness of continuation of WG > > Done First version WG I-D for Advertising TE Node Capabilities in > ISIS and OSPF > > Done First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > > Done Submit ASON Routing evaluation I-D for IESG review > > Done Cross-WG review of I-D for Advertising TE Node Capabilities in > ISIS and OSPF > > Done First version WG I-D MPLS to GMPLS migration strategies > > Done First version WG I-D Requirements for Multi-Layer and > Multi-Region Networks > > Done First version WG I-D for Evaluation of existing protocols for > MLN/MRN > > Done First version of WG I-D for ASON Routing solutions > > Done Submit RSVP-TE extensions for inter-domain signaling I-D for > IESG review > > Done Submit Per-domain path computation signaling I-D for IESG review > > > Done First version of WG I-D for OSPF-TE/GMPLS MIB module > > Done Submit GMPLS signaling in support of Call Management I-D for > IESG review > > Done First version WG Informational I-D for Analysis of inter-domain > issues for disjoint and protected paths > > Done Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF > for IESG review > > Done First version WG I-D for Protocol solutions for MLN/MRN > > Done Submit GMPLS/ASON lexicography I-D for IESG review > > Done First version WG I-D MPLS-GMPLS interworking requirements and > solutions > > Done Submit LSP Stitching I-D for IESG review > > Done Submit I-D for Automatic discovery of MPLS-TE mesh membership > for IESG review > > Done First version WG I-D GMPLS OAM Requirements > > Done Submit GMPLS routing and signaling interoperability advice I-D > for IESG review > > Done Submit MPLS to GMPLS migration strategies I-D for IESG review > > Done Submit Requirements for Multi-Layer and Multi-Region Networks > I-D for IESG review > > Done Submit MPLS-GMPLS interworking requirements and solutions I-D > for IESG review > > Done Submit Evaluation of existing protocols for MLN/MRN for IESG > review > > Feb 2007 First version of WG I-D for additional MIB module to cover > RSVP-TE signaling extensions > > Done First version WG I-Ds for GMPLS source-controlled and > explicitly-routed Ethernet networks > > Done Submit Informational I-D for Analysis of inter-domain issues for > disjoint and protected paths for IESG review > > Jan 2008 Submit ASON Routing solutions I-D for IESG review > > Feb 2008 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG > review > > Feb 2008 Submit GMPLS OAM Requirements I-D for IESG review > > Mar 2008 Submit Protocol solutions for MLN/MRN I-D for IESG review > > May 2008 Submit MIB module for RSVP-TE signaling extensions for MIB > doctor and IESG review > > Sep 2008 Submit protocol extensions for GMPLS source-controlled and > explicitly-routed Ethernet networks for IESG review > > Jan 2009 Recharter or close Working Group > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 May 2008 09:03:10 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-reqs-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080528090002.0CA1F3A6C9F@core3.amsl.com> Date: Wed, 28 May 2008 02:00:02 -0700 (PDT) --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-gmpls-mln-reqs-11.txt Pages : 27 Date : 2008-05-28 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. Expires November 2008 [page 1] draft-ietf-ccamp-gmpls-mln-reqs-11.txt May 2008 In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-28014703.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 May 2008 21:03:18 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080527210001.A7FF53A6826@core3.amsl.com> Date: Tue, 27 May 2008 14:00:01 -0700 (PDT) --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 : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-rfc4420bis-03.txt Pages : 22 Date : 2008-05-27 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rfc4420bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-27135247.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 May 2008 18:03:08 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080527180002.35A5B3A6B00@core3.amsl.com> Date: Tue, 27 May 2008 11:00:02 -0700 (PDT) --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 Labels for G.694 Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, H. Guo, K. Miyazaki, D. Caviglia Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt Pages : 10 Date : 2008-5-27 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-27105517.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 May 2008 18:06:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BCFF.2CCD7D79" Subject: Working Group Last Call Completed: draft-ietf-ccamp-gr-description-02 Date: Fri, 23 May 2008 14:02:32 -0400 Message-ID: Thread-Topic: Working Group Last Call Completed: draft-ietf-ccamp-gr-description-02 Thread-Index: AcivvDwYh3PM2WbnQICkg9X3bgptaANQnNdA From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BCFF.2CCD7D79 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable We completed the Last Call with comments incorporated in: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.t xt =20 I'll do the document shepherding. =20 Thanks, Deborah ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, May 06, 2008 5:01 PM To: ccamp@ops.ietf.org Subject: Working Group Last Call: draft-ietf-ccamp-gr-description-02 CCAMP, =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.t xt =20 Please send your comments to the mailing list prior to EOB May 20. =20 Adrian and Deborah ------_=_NextPart_001_01C8BCFF.2CCD7D79 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
We completed the Last Call with comments = incorporated=20 in:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-descri= ption-03.txt
 
I'll do the document = shepherding.
 
Thanks,
Deborah

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, May 06, 2008 5:01 PM
To:=20 ccamp@ops.ietf.org
Subject: Working Group Last Call:=20 draft-ietf-ccamp-gr-description-02

CCAMP,
 
This is to=20 initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-descri= ption-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 20.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8BCFF.2CCD7D79-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2008 16:34:49 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080519163002.302B93A69FD@core3.amsl.com> Date: Mon, 19 May 2008 09:30:02 -0700 (PDT) --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 : Description of the RSVP-TE Graceful Restart Procedures Author(s) : D. Li Filename : draft-ietf-ccamp-gr-description-03.txt Pages : 19 Date : 2008-5-19 The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gr-description-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-19092807.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2008 10:32:00 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080519103001.425E13A6E37@core3.amsl.com> Date: Mon, 19 May 2008 03:30:01 -0700 (PDT) --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 : draft-ietf-ccamp-pc-and-sc-reqs-04.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-and-sc-reqs-04.txt Pages : 11 Date : 2008-05-19 >From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-pc-and-sc-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-19032752.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2008 09:47:35 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080519094501.F28AE28C236@core3.amsl.com> Date: Mon, 19 May 2008 02:45:01 -0700 (PDT) --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 : draft-ietf-ccamp-pc-and-sc-reqs-03.txt Author(s) : D. Caviglia, D. Li Filename : draft-ietf-ccamp-pc-and-sc-reqs-03.txt Pages : 12 Date : 2008-05-19 >From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-pc-and-sc-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-19023916.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2008 07:44:22 +0000 Message-ID: <02fb01c8b983$f66cf810$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dan Li" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Date: Mon, 19 May 2008 08:42:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Dan, Thanks for the speedy response. Comments in line. >> 5.2.4. Procedures for scenario 4 >> >> Please capitalise section heading. >> >> You have: >> In the event that Node B never restarts, management plane >> intervention may be used at Node A to clean up any LSP state >> restored from the management plane or from local configuration. >> More importantly, management plane action is needed to clean up the >> data plane. >> > [Dan Li] Proposed text: > "In the event that Node B never restarts, management plane intervention is > needed at Node A to clean up any LSP state restored from the management > plane or from local configuration." Hmmm, maybe missed the point about the data plane? How about... In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP control plane state restored from the management plane or from local configuration, and to release any data plane resources." >> 5.2.5. Procedures for scenario 5 >> >> Please capitalise section heading. >> >> You have: >> In this scenario the Egress node (Node D) restarts, and its >> upstream neighbor (Node C) has not restarted. In this case, the >> Egress node is completely unaware of the LSPs. It has no downstream >> neighbor to help it, and no management plane or configuration >> information. The Egress node must simply wait until its upstream >> neighbor restarts and gives it the information as Path messages >> carrying RECOVERY_LABEL objects. >> It is not quite the case that the egress is "completely unaware" of >> the LSP as the data plane will be set up and carrying data (as >> described in the next section). >> > [Dan Li] Proposed text: > "...In this case, the Egress node may not aware of the LSPs...." Well, I would suggest.... In this scenario the Egress node (Node D) restarts, and its upstream neighbor (Node C) has not restarted. In this case, the Egress node may have no control plane state relating to the LSPs. It has no downstream neighbor to help it, and no management plane or configuration information, although there will be data plane state for the LSP. The Egress node must simply wait until its upstream neighbor restarts and gives it the information as Path messages carrying RECOVERY_LABEL objects. >> 7. Security Considerations > [SNIP] >> Note that the RSVP POLICY object [RFC2205] provides a scope by which >> secure end-to-end checks could be applied. However, very little >> definition of the use of this object has been made to date. > > [Dan Li] Do you mean RSVP POLICY_DATA object described in RFC 2205? Ah, yes. Good catch. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2008 07:18:04 +0000 Date: Mon, 19 May 2008 15:15:13 +0800 From: Dan Li Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 To: Adrian Farrel , "BRUNGARD, DEBORAH A, ATTLABS" , ccamp@ops.ietf.org Message-id: <110801c8b980$14fa4e80$3d4d460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Adrian, Thanks for the very detailed comments! The proposed text for most of the editorial issues will be accepted in the next version. Still have several issues letf, and II proposed the text: > === > 5.2.4. Procedures for scenario 4 > > Please capitalise section heading. > > You have: > In the event that Node B never restarts, management plane > intervention may be used at Node A to clean up any LSP state > restored from the management plane or from local configuration. > More importantly, management plane action is needed to clean up the > data plane. > [Dan Li] Proposed text: "In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP state restored from the management plane or from local configuration." > === > 5.2.5. Procedures for scenario 5 > > Please capitalise section heading. > > You have: > In this scenario the Egress node (Node D) restarts, and its > upstream neighbor (Node C) has not restarted. In this case, the > Egress node is completely unaware of the LSPs. It has no downstream > neighbor to help it, and no management plane or configuration > information. The Egress node must simply wait until its upstream > neighbor restarts and gives it the information as Path messages > carrying RECOVERY_LABEL objects. > It is not quite the case that the egress is "completely unaware" of > the LSP as the data plane will be set up and carrying data (as > described in the next section). > [Dan Li] Proposed text: "...In this case, the Egress node may not aware of the LSPs...." > 7. Security Considerations [SNIP] > Note that the RSVP POLICY object [RFC2205] provides a scope by which > secure end-to-end checks could be applied. However, very little > definition of the use of this object has been made to date. [Dan Li] Do you mean RSVP POLICY_DATA object described in RFC 2205? Thanks, Dan ----- Original Message ----- From: "Adrian Farrel" To: "BRUNGARD, DEBORAH A, ATTLABS" ; Sent: Monday, May 19, 2008 5:13 AM Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 > Hi, > > Well written draft. Thanks. > > Here are some comments. Most of them are small editorial issues. > > Regards, > Adrian > > === > idnits > tmp/draft-ietf-ccamp-gr-description-02.txt(191): Line is too long: the > offending characters are ',' > > === > 1. Introduction > > Recovery Label object > > Please be consistent with the names for all objects within this I-D. > Mainly you use upper case, for example, RECOVERY_LABEL object > > s/provides and informational/provides an informational/ > > === > 2.1. Procedures defined in [RFC3473] > > Please capitalise section heading. > > s/2) Recovers its RSVP state/2) Recover its RSVP state/ > > s/state in data plane/state in the data plane/ > > s/is not existed/does not exist/ > > s/state in data plane is existed/state in the data plane exists/ > > You have: > > For the Restarting Node: > [SNIP] > 4) > [SNIP] > In addition, if the node is not > the tail-end of the LSP, the corresponding outgoing Path messages is > sent with the incoming label from that entry carried in the > UPSTREAM_LABEL object. > "incoming label from that entry" is correct, but may be confusing. > How about... > In addition, if the node is not the tail-end of the LSP, the incoming > label on the downstream interface is retrieved from the forwarding > state on the restarting node and set in the UPSTREAM_LABEL object in > the Path message sent to the downstream neighbor. > > s/1) Sends the Path message/1) Sends a Path message/ > > === > 2.2. Procedures defined in [RFC5063] > > s/in [RFC5063] which is called the/in [RFC5063] called the / > > s/From the received Path message the following state can be recovered:/ > The following state can be recovered from the received Path message:/ > > s/From the received RecoveryPath message the following state can be > recovered:/ > The following state can be recovered from the received RecoveryPath > message:/ > > s/either by regular Path message or RecoveryPath message, and Resv message./ > either from the regular Path and Resv messages, or from the RecoveryPath > message./ > > === > 3. Multiple Node Restart Scenarios > > s/Note that if multi nodes/Note that if multiple nodes/ > > === > 5.2.2. Procedures for Scenario 2 > > s/node(Node A)/node (Node A)/ > > === > 5.2.3. Procedures for scenario 3 > > Please capitalise section heading. > > s/on the nodes that are waiting/on the node that is waiting/ > > === > 5.2.4. Procedures for scenario 4 > > Please capitalise section heading. > > You have: > In the event that Node B never restarts, management plane > intervention may be used at Node A to clean up any LSP state > restored from the management plane or from local configuration. > More importantly, management plane action is needed to clean up the > data plane. > > === > 5.2.5. Procedures for scenario 5 > > Please capitalise section heading. > > You have: > In this scenario the Egress node (Node D) restarts, and its > upstream neighbor (Node C) has not restarted. In this case, the > Egress node is completely unaware of the LSPs. It has no downstream > neighbor to help it, and no management plane or configuration > information. The Egress node must simply wait until its upstream > neighbor restarts and gives it the information as Path messages > carrying RECOVERY_LABEL objects. > It is not quite the case that the egress is "completely unaware" of > the LSP as the data plane will be set up and carrying data (as > described in the next section). > > === > 6. Clarification of Restarting Node Procedure > > In the figure, you have > X(CON deletion) X (CON deletion) > I suggest you replace this with > X(LSP deletion) X (LSP deletion) > > Please add a caption for the figure. Such as, > > Figure 2 Message flow for accidental LSP deletion > > c/hello/Hello/ (several times) > > To resolve the aforementioned problem, the following procedures are > proposed and are meant to work together with the recovery > procedures documented in [RFC3473]. Here, it is assumed that the > restarting node and the neighboring node(s) support Hello extension > as documented in [RFC3209] and recovery procedures documented in > [RFC3473]. > This paragraph implies that there *are* new procedures defined in this > document contrary to the promise in the Abstract and Introduction. > I suggest you change the text as follows... > To resolve the aforementioned problem, the following procedures which > are implicit in [RFC3473] and [RFC5063] should be followed. These > procedures work together with the recovery procedures documented in > [RFC3473]. Here, it is assumed that the restarting node and the > neighboring node(s) support Hello extension as documented in > [RFC3209] and recovery procedures documented in [RFC3473]. > > === > 7. Security Considerations > > We had some debate with the Security ADs when RFC 5063 was processed. We > need to fill out the text in this section a little to reflect those > comments. > > I suggest replacing the existing text with the following... > > This document clarifies the procedures defined in [RFC3473] and > [RFC5063] to be performed on RSVP agents that neighbor one or more > restarting RSVP agents. It does not introduce any new procedures and, > therefore, does not introduce any new security risks or issues. > > In the case of the control plane in general, and the RSVP agent in > particular, where one or more nodes carrying one or more LSPs are > restarted due to external attacks, the procedures defined in > [RFC5063] and described in this document provide the ability for > the restarting RSVP agents to recover the RSVP state in each > restarting node corresponding to the LSPs, with the least possible > perturbation to the rest of the network. These procedures can be > considered to provide mechanisms by which the GMPLS network can > recover from physical attacks or from attacks on remotely controlled > power supplies. > > The procedures described are such that, only the neighboring RSVP > agents should notice the restart of a node, and hence only they need > to perform additional processing. This allows for a network with > active LSPs to recover LSP state gracefully from an external attack, > without perturbing the data/forwarding plane state, and without > propagating the error condition in the control or data plane. In > other words, the effect of the restart (which might be the result of > an attack) does not spread into the network. > > Note that concern has been expressed about the vulnerability of a > restarting node to false messages received from its neighbors. For > example, a restarting node might receive a false Path message with a > Recovery Label object from an upstream neighbor, or a false > RecoveryPath message from its downstream neighbor. This situation > might arise in one of four cases: > > - The message is spoofed and does not come from the neighbor at all. > - The message has been modified as it was travelling from the > neighbor. > - The neighbor is defective and has generated a message in error. > - The neighbor has been subverted and has a "rogue" RSVP agent. > > The first two cases may be handled using standard RSVP authentication > and integrity procedures [RFC3209], [RFC3473]. If the operator is > particularly worried, the control plane may be operated using IPsec > [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411] > > Protection against defective or rogue RSVP implementations is > generally hard to impossible. Neighbor-to-neighbor authentication > and integrity validation is, by definition, ineffective in these > situations. For example, if a neighbor node sends a Resv during > normal LSP setup, and if that message carries a GENERALIZED_LABEL > object carrying an incorrect label value, then the receiving LSR will > use the supplied value and the LSP will be set up incorrectly. > Alternatively, if a Path message is modified by an upstream LSR to > change the destination and explicit route, there is no way for the > downstream LSR to detect this, and the LSP may be set up to the wrong > destination. Furthermore, the upstream LSR could disguise this fact by > modifying the recorded route reported in the Resv message. Thus, these > issues are in no way specific to the restart case, do not cause any > greater or different problems from the normal case, and do not warrant > specific security measure applicable to restart scenarios. > > Note that the RSVP POLICY object [RFC2205] provides a scope by which > secure end-to-end checks could be applied. However, very little > definition of the use of this object has been made to date. > > See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS > networks. > > > === > 10.2. Informative References > > Replace with... > > [MPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS > Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework, work > in progress. > > [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document > Roadmap," November 1998. > > [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet > Protocol," December 2005. > > [RFC4302] S. Kent, "IP Authentication Header," December 2005. > > [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) > Protocol", December 2005. > > [RFC4835] V. Manral, "Cryptographic Algorithm Implementation > Requirements for Encapsulating Security Payload (ESP) and > Authentication Header (AH)", April 2007. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 May 2008 21:15:24 +0000 Message-ID: <028d01c8b92c$02eb8c30$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "BRUNGARD, DEBORAH A, ATTLABS" , Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Date: Sun, 18 May 2008 22:13:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Well written draft. Thanks. Here are some comments. Most of them are small editorial issues. Regards, Adrian === idnits tmp/draft-ietf-ccamp-gr-description-02.txt(191): Line is too long: the offending characters are ',' === 1. Introduction Recovery Label object Please be consistent with the names for all objects within this I-D. Mainly you use upper case, for example, RECOVERY_LABEL object s/provides and informational/provides an informational/ === 2.1. Procedures defined in [RFC3473] Please capitalise section heading. s/2) Recovers its RSVP state/2) Recover its RSVP state/ s/state in data plane/state in the data plane/ s/is not existed/does not exist/ s/state in data plane is existed/state in the data plane exists/ You have: For the Restarting Node: [SNIP] 4) [SNIP] In addition, if the node is not the tail-end of the LSP, the corresponding outgoing Path messages is sent with the incoming label from that entry carried in the UPSTREAM_LABEL object. "incoming label from that entry" is correct, but may be confusing. How about... In addition, if the node is not the tail-end of the LSP, the incoming label on the downstream interface is retrieved from the forwarding state on the restarting node and set in the UPSTREAM_LABEL object in the Path message sent to the downstream neighbor. s/1) Sends the Path message/1) Sends a Path message/ === 2.2. Procedures defined in [RFC5063] s/in [RFC5063] which is called the/in [RFC5063] called the / s/From the received Path message the following state can be recovered:/ The following state can be recovered from the received Path message:/ s/From the received RecoveryPath message the following state can be recovered:/ The following state can be recovered from the received RecoveryPath message:/ s/either by regular Path message or RecoveryPath message, and Resv message./ either from the regular Path and Resv messages, or from the RecoveryPath message./ === 3. Multiple Node Restart Scenarios s/Note that if multi nodes/Note that if multiple nodes/ === 5.2.2. Procedures for Scenario 2 s/node(Node A)/node (Node A)/ === 5.2.3. Procedures for scenario 3 Please capitalise section heading. s/on the nodes that are waiting/on the node that is waiting/ === 5.2.4. Procedures for scenario 4 Please capitalise section heading. You have: In the event that Node B never restarts, management plane intervention may be used at Node A to clean up any LSP state restored from the management plane or from local configuration. More importantly, management plane action is needed to clean up the data plane. === 5.2.5. Procedures for scenario 5 Please capitalise section heading. You have: In this scenario the Egress node (Node D) restarts, and its upstream neighbor (Node C) has not restarted. In this case, the Egress node is completely unaware of the LSPs. It has no downstream neighbor to help it, and no management plane or configuration information. The Egress node must simply wait until its upstream neighbor restarts and gives it the information as Path messages carrying RECOVERY_LABEL objects. It is not quite the case that the egress is "completely unaware" of the LSP as the data plane will be set up and carrying data (as described in the next section). === 6. Clarification of Restarting Node Procedure In the figure, you have X(CON deletion) X (CON deletion) I suggest you replace this with X(LSP deletion) X (LSP deletion) Please add a caption for the figure. Such as, Figure 2 Message flow for accidental LSP deletion c/hello/Hello/ (several times) To resolve the aforementioned problem, the following procedures are proposed and are meant to work together with the recovery procedures documented in [RFC3473]. Here, it is assumed that the restarting node and the neighboring node(s) support Hello extension as documented in [RFC3209] and recovery procedures documented in [RFC3473]. This paragraph implies that there *are* new procedures defined in this document contrary to the promise in the Abstract and Introduction. I suggest you change the text as follows... To resolve the aforementioned problem, the following procedures which are implicit in [RFC3473] and [RFC5063] should be followed. These procedures work together with the recovery procedures documented in [RFC3473]. Here, it is assumed that the restarting node and the neighboring node(s) support Hello extension as documented in [RFC3209] and recovery procedures documented in [RFC3473]. === 7. Security Considerations We had some debate with the Security ADs when RFC 5063 was processed. We need to fill out the text in this section a little to reflect those comments. I suggest replacing the existing text with the following... This document clarifies the procedures defined in [RFC3473] and [RFC5063] to be performed on RSVP agents that neighbor one or more restarting RSVP agents. It does not introduce any new procedures and, therefore, does not introduce any new security risks or issues. In the case of the control plane in general, and the RSVP agent in particular, where one or more nodes carrying one or more LSPs are restarted due to external attacks, the procedures defined in [RFC5063] and described in this document provide the ability for the restarting RSVP agents to recover the RSVP state in each restarting node corresponding to the LSPs, with the least possible perturbation to the rest of the network. These procedures can be considered to provide mechanisms by which the GMPLS network can recover from physical attacks or from attacks on remotely controlled power supplies. The procedures described are such that, only the neighboring RSVP agents should notice the restart of a node, and hence only they need to perform additional processing. This allows for a network with active LSPs to recover LSP state gracefully from an external attack, without perturbing the data/forwarding plane state, and without propagating the error condition in the control or data plane. In other words, the effect of the restart (which might be the result of an attack) does not spread into the network. Note that concern has been expressed about the vulnerability of a restarting node to false messages received from its neighbors. For example, a restarting node might receive a false Path message with a Recovery Label object from an upstream neighbor, or a false RecoveryPath message from its downstream neighbor. This situation might arise in one of four cases: - The message is spoofed and does not come from the neighbor at all. - The message has been modified as it was travelling from the neighbor. - The neighbor is defective and has generated a message in error. - The neighbor has been subverted and has a "rogue" RSVP agent. The first two cases may be handled using standard RSVP authentication and integrity procedures [RFC3209], [RFC3473]. If the operator is particularly worried, the control plane may be operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411] Protection against defective or rogue RSVP implementations is generally hard to impossible. Neighbor-to-neighbor authentication and integrity validation is, by definition, ineffective in these situations. For example, if a neighbor node sends a Resv during normal LSP setup, and if that message carries a GENERALIZED_LABEL object carrying an incorrect label value, then the receiving LSR will use the supplied value and the LSP will be set up incorrectly. Alternatively, if a Path message is modified by an upstream LSR to change the destination and explicit route, there is no way for the downstream LSR to detect this, and the LSP may be set up to the wrong destination. Furthermore, the upstream LSR could disguise this fact by modifying the recorded route reported in the Resv message. Thus, these issues are in no way specific to the restart case, do not cause any greater or different problems from the normal case, and do not warrant specific security measure applicable to restart scenarios. Note that the RSVP POLICY object [RFC2205] provides a scope by which secure end-to-end checks could be applied. However, very little definition of the use of this object has been made to date. See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS networks. === 10.2. Informative References Replace with... [MPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework, work in progress. [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap," November 1998. [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet Protocol," December 2005. [RFC4302] S. Kent, "IP Authentication Header," December 2005. [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", December 2005. [RFC4835] V. Manral, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", April 2007. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 May 2008 10:51:39 +0000 Message-ID: <027401c8b8d4$b2902db0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "BRUNGARD, DEBORAH A, ATTLABS" , Subject: Re: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02 Date: Sun, 18 May 2008 11:46:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I have done a chair review on this draft and found some small editorial updates that should be made before the I-D goes forward. If the editors could resolve these and submit an update, we will be ready for Deborah to take the I-D to the IESG. Thanks, Adrian idnits == It seems as if not all pages are separated by form feeds - found 1 form feeds but 12 pages == Unused Reference: 'RFC 3473' is defined on line 406, but no explicit reference was found in the text === General points - I think you should decide whether management plane, control plane, and data plane are capitalized or not, and apply this to the whole document. - Conventionally, references (such as [RFC1234]) do not include spaces (i.e., not [RFC 1234]) === 1. Introduction s/endpoints/end-points/ OLD At least some control plane initiated aspects of a connection must be capable of being queried by the management plane. These aspects should be independent of how the connection was established. NEW At least some aspects of a control plane initiated connection must be capable of being queried by the management plane. These aspects should be independent of how the connection was established. === 2. Motivation s/or SC interoperation is achieved/or before SC interoperation is achieved/ s/is proposed as/is stated as/ s/is seen as a nice to have, or desirable, feature/is a desirable feature/ s/should be scoped as/is scoped as/ === 3. Label Switched Path Terminology s/(such as Path and Resv state)/(such as RSVP-TE [RFC3473] Path and Resv state)/ I think you should note that control plane LSPs may be visible and controlable through the management plane. That is, the control plane LSP may have been requested through a management plane operation, and can be reported and inspected by/at the transit LSR. Further, it is generally the case that management plane operations can be carried out on the resources of active control plane LSPs even at transit LSRs. You can then say that this is not the function that you are talking about. === 4. LSP within GMPLS Control Plane Include a refernce to RFC 3945 as you are talking about GMPLS architecture. === 4.1. Resource Ownership At the end of the first paragraph, you have... Note that the management plane assigns resources to the control plane. I think this is confusing in the context of the rest of the text in the paragrpah that defines 'ownership' of resources in relation to the setup of an LSP. Doesn't the sentence actually belong in the next paragraph? I.e., Note that the management plane assigns resources as available for ownership by the control plane. Or even just delete this sentence. === 4.2. Setting Up a GMPLS Controlled Network You have... When converting from an SC to a PC, the management plane must change the owner of each hop. Somehow, then the instance in the control plane must be removed without affecting the data plane. This may best be done via a make before break operation. This last sentence is odd! There is no "make-before-break operation" to be performed as there is no change in the data plane. I suggest that you simply remove this sentence which, in any case, is pre-judging the solution (which this document should avoid doing). === 5.1. PC to SC/SPC Conversion s/Next step in such conversion/The next step in this conversion/ You have... In this case a network upgrade by a Control Plane coverage extension may be required. Huh? The phrase "Control Plane coverage extension" didn't mean anything to me (although I can make some guesses). Can you clarify in the text, please. === 6. Requirements Suggest you add... Notation from [RFC2119] is used to clarify the level of each requirement. === 6.2. No Disruption of User Traffic SC to PC conversion and vice-versa shall occur without generating s/shall/SHALL/ ? === 6.5. Synchronization of state among nodes during conversion Please capitalize the section heading It MUST be assured that the state of the LSP is synchronized among all nodes traversed by it before proceeding to the conversion. Does "before proceeding to the conversion" mean "before the conversion is considered complete"? Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2008 17:33:20 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-wavelength-switched-framework-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080514173002.08D213A6955@core3.amsl.com> Date: Wed, 14 May 2008 10:30:02 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, Y. Lee, W. Imajuku Filename : draft-ietf-ccamp-wavelength-switched-framework-00.txt Pages : 34 Date : 2008-5-13 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wavelength-switched-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-wavelength-switched-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-14102709.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2008 07:47:41 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-path-key-ero-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080514074501.8168E3A6853@core3.amsl.com> Date: Wed, 14 May 2008 00:45:01 -0700 (PDT) --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 : RSVP Extensions for Path Key Support Author(s) : R. Bradford, et al. Filename : draft-ietf-ccamp-path-key-ero-01.txt Pages : 8 Date : 2008-05-14 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCE supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS). This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so facilitate confiedntiality in the signaling of inter-domain TE LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-path-key-ero-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-14004042.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2008 01:40:55 +0000 From: "Soichiro Araki" To: , , , Cc: Subject: Call for PARTICIPATION - 4th InternationalConference on IP + Optical Network (iPOP 2008) Date: Wed, 14 May 2008 10:37:53 +0900 Organization: NEC Corp. Message-Id: <002d01c8b563$20945180$8883380a@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Thread-Index: Aci0iuWQmOlMAus8TZGRvUr4IXtYTwA1s1jA +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [Our apologies if you receive multiple copies of this message] ***************************************************************** * CALL FOR PARTICIPATION * * * * Conference on IP + Optical Network (iPOP208) * * http://www.ipop2008.com/ * * * * June 5-6, 2008 Tokyo, Japan * * * * Participation fee: free * * * * Please register through * * http://www.pilab.jp/ipop2008/registration/index.html * ***************************************************************** ----------------------------------------------------------------------------- Technical Sessions ----------------------------------------------------------------------------- Day 1 (June 5, 2008) ----------------------------------------------------------------------------- Tech. Session 1: ASON Chair: Kireeti Kompella, Juniper, USA o "Control Plane Resilience and Security in GMPLS Networks : Fact and Fiction," Adrian Farrel (Old Dog Consulting, UK) o "e2e GMPLS P&R with next generation interface for the green networking," Hidetsugu Sugiyama (Juniper Networks, Japan) o "Automated End-to-end Circuit Provisioning for high bandwidth demand applications: the challenges and our experiences in 3TNet," Weiqiang Sun, Guowu Xie, Yaohui Jin, Wei Guo and Weisheng Hu (Shanghai Jiao Tong University, P. R. China) ----------------------------------------------------------------------------- Tech. Session 2: WSON Chair: Wataru Imajuku, NTT, Japan o "GMPLS Extensions in Support of All-optical Networking," Hongxiang Guo, Takehiro Tsuritani, Noboru Yoshikane, Tomohiro Otani (KDDI R&D, Japan) o "Optical Reach Computation with GMPLS," Snigdho Bardalai, Richard Colter, Sugiya Hideaki, Fred Gruman, Mike White, Sanjay Gera (Fujitsu, USA) o "GMPLS perspectives to control WSON," Pierre Peloso, Benoit RONOT, Martin VIGOUREUX, Richard DOUVILLE (Alcatel-Lucent, France) o "Wavelength Switched Optical Networks with Distributed Control," Hiroaki Harai and Sugang Xu (NICT, Japan) ----------------------------------------------------------------------------- Day 2 (June 6, 2008) ----------------------------------------------------------------------------- Tech. Session 3: PCE Chair: Young Lee, Huawei, USA o "Inter-Carrier PCE-Based Path Computation in Keihanna Interoperablity Project" Tomonori Takeda, Eiji Oki (NTT, Japan), Yohei Iizawa, Itaru Nishioka (NEC, Japan), Machiko Asaie, Kazuhiro Kusama (Hitachi, Japan), Shuichi Okamoto, and Tomohiro Otani (KDDI R&D, Japan) o "End-to-End path routing with PCEs in multi-domain GMPLS networks" Itaru Nishioka, Shinya Ishida, Yohei Iizawa (NEC, Japan) o "Path Computation Issues and Solutions in Wavelength Switched Optical Networks (WSON)" Young Lee (Huawei, USA), Greg Bernstein (Grotto Networks, USA), Daniel King (Aria-Networks, UK) o "Deploying Advanced Path Computation Technologies for Optical Transport Networks," Daniel King (Aria Networks, UK), Takehiro Tsuritani (KDDI R&D, Japan) ----------------------------------------------------------------------------- Tech. Session 4: GELS Chair: Don Fedyk, Nortel, USA o "Experimenting with GMPLS to control a PBB-TE network" Benoit Tremblay, Attila Takacs, Howard Green (Ericsson Research, Canada) o "Employing GMPLS control for PBB-TE networks" Don Fedyk (Nortel, USA) o "Example of a GMPLS control plane interconnected with an Ethernet data plane in a rack-mounted prototype" A. Dupas, R. Boislaigue, C. Cosse-maniere, G.Post, M. Lorret (Alcatel-lucent Bell-labs, France) ----------------------------------------------------------------------------- Tech. Session 5: OAM Chair: Adrian Farrel, Old Dog Consulting, UK o "Design, implementation and validation within ADRENALINER testbed of a Path Computation Element for Wavelength Switched Optical Networks," Ramon Casellas, Ricardo Martinez, Raul Munoz (CTTC, Spain) o "GMPLS OAM Tool Kit" Zafar Ali, Roberto Cassata, (Cisco, USA), T. Otani, (KDDI R&D, Japan), Marco Anisetti, Valerio Bellandi, Ernesto Damiani, Francesco Diana, Umberto Raimondi (University of Milan, Italy) o "Lessons learned from operational experience on the JGN II GMPLS network test bed" S. Okamoto and T. Otani (KDDI R&D, Japan) o "Service and Architecture of GMPLS-Controlled Photonic Internet Exchange" Yoshiaki Sone, Wataru Imajuku, Ippei Shake, Kazuhiro Matsuda (NTT, Japan), Tomohiko Kurahashi, Junichi Shimagami, Toshiya Asaba, (IIJ, Japan), Yukiyasu Tarui, Nobuhisa Miyake, Katsuyasu Toyama (Internet Multifeed, Japan) ----------------------------------------------------------------------------- Tech. Session 6: MLN Chair: Tomohiro Otani, KDDI R&D, Japan o "Is SRLG Optimization a Business Case for GMPLS Deployment?" Stefan Schnitter, Martin Horneffer (Deutsche Telekom, Germany) o "GMPLS based Multi Layer Service Network Architecture and Layer 1 On Demand Service Resource Management" Ichiro Inoue, Kaori Shimizu, Rie Hayashi, Hisashi Kojima, Kohei Shiomoto, (NTT, Japan), Shigeo Urushidani (NII, Japan) o "Next Steps for Deploying Multi-layer Traffic Engineered Networks" Steve West (Cyan Optics, USA), Peter Willis (BT, UK), Daniel King (Aria Networks, UK) ----------------------------------------------------------------------------- Poster Session ----------------------------------------------------------------------------- Day 1 (June 5, 2008) ----------------------------------------------------------------------------- Poster Session Chair: Ernesto Damiani, University of Milan, Italy o "Optical Fast Reroute," Adrian Farrel (Old Dog Consulting, UK) o "GMPLS VLAN Path Establishment using Inter-domain VLAN Tag Swapping," Kou Kikuta, Masahiro Nishida, Daisuke Ishii, Satoru Okamoto, Naoaki Yamanaka (KEIO University, Japan) o "Chromatic Dispersion Compensation Control in Dynamically Reconfigurable All-Optical Networks," Eiichi Horiuchi, Misato Kamei, Shoichiro Seno, and Yoshimasa Baba (Mitsubishi Electric Corporation, Japan) o "IGP Extentension for RWA in WSON," Jianrui Han, Dan Li, Jianhua Gao, Young Lee (Huawei Technologies, P.R.China) o "Establishing Inter-domain services," Richard Douville, Helia Pouyllau (Alcatel-lucent Bell-labs, France) o "SShared Backup Mesh Protection in PCE-based WSON networks," Greg Bernstein (Grotto Networks, USA), Young Lee (Huawei, USA) o "P2MP Path Computation & Operation in MPLS & Optical Networks," Quintin Zhao (Huawei, USA), Daniel King (Aria Networks, UK), Fabien Verhaeghe (Marben, France), Tomonori Takeda (NTT, Japan) ----------------------------------------------------------------------------- Exhibition ----------------------------------------------------------------------------- o Exhibition participants Keio University KDDI Laboratories NTT NICT NEC Anritsu ISOCORE Tokyo University Juniper Networks OIF Infinera Tellabs o Showcase Participants Kei-han-na Open Lab Lambda UTILITY ------------------------------------------------------------------------------- Sponsors ------------------------------------------------------------------------------- o Sponsored by Photonic Internet Lab. (http://www.pilab.jp) ISOCORE (http://www.isocore.com$B!K(B o Supported by Photonic Internet Forum (http://www.scat.or.jp/photonic/$B!K(B Kei-han-na Open Lab (http://www.khn-openlab.jp/bunkakai-gw/kokino-net/sousetsu/index-j.html) Council for Info-Communication Promotions Month(http://www.jtgkn.com/) *iPOP2008 is an Event of Info-Communication Promotions Month ------------------------------------------------------------------------------- Best regards, -Soichiro Araki Organization Committee Co-Chair, iPOP 2008 http://www.ipop2008.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Soichiro ARAKI System Platforms Research Laboratories, NEC Corporation E-mail: s-araki@cj.jp.nec.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2008 08:06:35 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512181502.325393A67EE@core3.amsl.com> Date: Mon, 12 May 2008 11:15:02 -0700 (PDT) Cc: ccamp@ops.ietf.org Reply-To: internet-drafts@ietf.org --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro Filename : draft-ietf-ccamp-gmpls-mln-reqs-10.txt Pages : 26 Date : 2008-5-12 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12110542.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2008 00:19:19 +0000 Message-ID: <4828DDA1.1020409@kddilabs.jp> Date: Tue, 13 May 2008 09:15:29 +0900 From: Tomohiro Otani User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" Cc: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Deboraha, I will upload the revised document shortly. Regards, Tomo BRUNGARD, DEBORAH A, ATTLABS =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D= =E3=81=BE=E3=81=97=E3=81=9F: > Hi, > We have good support for both of these documents. > Authors, please submit your documents with the following titles: > Framework (same title as now): > Framework for GMPLS and PCE Control of Wavelength Switched Optical=20 > Networks (WSON) > draft-ietf-ccamp-wavelength-switched-framework-00.txt > Labels (different title proposed): > Generalized Labels for G.694 Lambda-Switching Capable Label Switching=20 > Routers > draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt > Thanks, > Adrian and Deborah > > -----------------------------------------------------------------------= - > *From:* owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] *On=20 > Behalf Of *BRUNGARD, DEBORAH A, ATTLABS > *Sent:* Tuesday, April 29, 2008 11:39 AM > *To:* ccamp@ops.ietf.org > *Subject:* Poll for WG Adoption of Two WSON documents > > CCAMP, > From Philadelphia, we had good support for adoption of two of the WSON=20 > documents as CCAMP working group documents: > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-sw= itched-03.txt > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labe= ls-02.txt > Please express your opinions (authors, we welcome your opinion also). > Thanks, > Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2008 18:16:43 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080512181502.325393A67EE@core3.amsl.com> Date: Mon, 12 May 2008 11:15:02 -0700 (PDT) --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro Filename : draft-ietf-ccamp-gmpls-mln-reqs-10.txt Pages : 26 Date : 2008-5-12 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-12110542.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2008 15:52:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B447.EE8157F4" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Mon, 12 May 2008 10:50:40 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF111C79E6@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAKN2veg From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B447.EE8157F4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 We have good support for both of these documents. =20 Authors, please submit your documents with the following titles: Framework (same title as now): Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) draft-ietf-ccamp-wavelength-switched-framework-00.txt =20 Labels (different title proposed): Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt =20 Thanks, Adrian and Deborah =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 11:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8B447.EE8157F4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
We have good support for both of these=20 documents.
 
Authors, please submit your documents with = the=20 following titles:
Framework (same title as = now):
Framework for GMPLS and PCE = Control of=20 Wavelength Switched Optical Networks (WSON)
draft-ietf-ccamp-wavelength-switched-framework-00.txt
 
Labels=20 (different title proposed):
Generalized Labels for G.694 = Lambda-Switching=20 Capable Label Switching Routers
draft-ietf-ccamp-gmpls-g-694-lambda-labels-00.txt<= /DIV>
 
Thanks,
Adrian and Deborah
 

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, April 29, 2008 11:39 AM
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON=20 documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8B447.EE8157F4-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2008 15:38:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B445.C1A5574B" Subject: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02 Date: Mon, 12 May 2008 10:35:06 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF111C79A8@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02 Thread-Index: AcinAma4cVOgNqu6REeXIW68/i9pSwNQpY7A From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B445.C1A5574B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 We completed the last call on draft-ietf-ccamp-pc-and-sc-reqs-02 with no comments/no updates needed. =20 I'll do the document shepherding. =20 Thanks, Deborah ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Friday, April 25, 2008 2:30 PM To: ccamp@ops.ietf.org Subject: Working Group Last Call: draft-ietf-ccamp-pc-and-sc-reqs-02 WG, =20 To ensure you have weekend reading material (especially here in the NE with our yet another rainy weekend), we have two more documents which we discussed in Phila to Last Call. I'll send separate mails. =20 And don't forget the Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end tomorrow. =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.t xt =20 Please send your comments to the mailing list prior to EOB May 9. =20 Adrian and Deborah ------_=_NextPart_001_01C8B445.C1A5574B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
We completed the last call on=20 draft-ietf-ccamp-pc-and-sc-reqs-02 with no comments/no updates=20 needed.
 
I'll do the document = shepherding.
 
Thanks,
Deborah

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Friday, April 25, 2008 2:30 PM
To:=20 ccamp@ops.ietf.org
Subject: Working Group Last Call:=20 draft-ietf-ccamp-pc-and-sc-reqs-02

WG,
 
To = ensure you have=20 weekend reading material (especially here in the NE with our yet=20 another rainy weekend), we have two more documents which we = discussed in=20 Phila to Last Call. I'll send separate mails.
 
And = don't forget the=20 Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end=20 tomorrow.
 
This = is to initiate=20 a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc= -reqs-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 9.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8B445.C1A5574B-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2008 12:03:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] [mpls] proposed charter update for the MPLS TP work Date: Mon, 12 May 2008 12:55:50 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C02653B26@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: [PWE3] [mpls] proposed charter update for the MPLS TP work Thread-Index: Aci0AvvVV4jxuwRrSG6pvaXj9JFLbwAI4tuQ From: To: , , Cc: , , , Loa/Adrian/Stewart, I think it would be really useful if someone could summarise what specific proposals/options are being considered for MPLS-TP. In particular, given: - most operators would regard an OOB CP as an essential component of a transport network (and this is a forced requirement in the co-cs mode anyway); - GMPLS already uses an OOB CP and there is a long-standing CCAMPs charter item to unify the GMPLS/MPLS CPs; - I believe re-using common CP techniques would also be of interest to many operators; then it would appear that the MPLS-TP initiative provides a very good opportunity to address this. Any comments? regards, Neil=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Loa Andersson > Sent: 12 May 2008 08:34 > To: Adrian Farrel > Cc: stbryant@cisco.com; Shahram Davari; 'ccamp'; mpls@ietf.org; 'pwe3' > Subject: Re: [PWE3] [mpls] proposed charter update for the=20 > MPLS TP work >=20 >=20 > All, >=20 >=20 >=20 > Adrian Farrel wrote: > > Hi, > >=20 > > Perhaps... > > OLD > > Include extensions to the [MPLS, PWE3, CCAMP] protocols > > NEW > > Include modifications and extensions to the [MPLS, PWE3, CCAMP] > > protocols and procedures >=20 > my take on this that we are talking about "extensions"=20 > relative the the existing specification, it is quite possible=20 > for an extension to leave "components of the MPLS=20 > architecture unused", that is in fact the case with most of=20 > our documents. >=20 > Consequently I agree with Stewart, and would oppose words=20 > like, reduce and modify, since that implies that we intend to=20 > *change* the MPLS architecture, while one of the foundations=20 > of the agreement to create an MPLS TP was that it should fit=20 > into the MPLS architecture. >=20 > /Loa > >=20 > > Adrian > >=20 > > ----- Original Message ----- From: "Stewart Bryant"=20 > > > > To: "Shahram Davari" > > Cc: "'ccamp'" ; ; "'pwe3'"=20 > > > > Sent: Friday, May 09, 2008 9:52 PM > > Subject: Re: [PWE3] [mpls] proposed charter update for the=20 > MPLS TP work > >=20 > >=20 > >> I think it was fine as it was. We are not going to do and=20 > unnecessary=20 > >> extensions, and we are not going to remove any=20 > functionality that is=20 > >> already in there because we need it for other applications. > >> > >> We could perhaps say: > >> > >> "Include necessary extensions ...." to make it completely clear. > >> > >> Stewart > >> > >> Shahram Davari wrote: > >>> Hi Loa, > >>> > >>> Just a clarification. The term reduction means components of the=20 > >>> MPLS architecture left unused. > >>> > >>> Regards, > >>> Shahram > >>> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org=20 > [mailto:mpls-bounces@ietf.org] On Behalf=20 > >>> Of Shahram Davari > >>> Sent: May-09-08 2:52 PM > >>> To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' > >>> Subject: Re: [mpls] proposed charter update for the MPLS TP work > >>> > >>> Hi Loa, > >>> > >>> The term "extension" is not very appropriate. It doesn't cover the > >>> possible > >>> case of MPLS TP requiring a reduction in MPLS functionality? > >>> > >>> How about changing that to "extensions and reductions" > >>> > >>> Regards, > >>> -Shahram > >>> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org=20 > [mailto:mpls-bounces@ietf.org] On Behalf > >>> Of Loa > >>> Andersson > >>> Sent: May-09-08 6:57 AM > >>> To: ccamp; mpls@ietf.org; pwe3 > >>> Subject: [mpls] proposed charter update for the MPLS TP work > >>> > >>> MPLS, CCAMP and PWE3 working groups, > >>> > >>> > >>> The Joint Working Team of the IETF and ITU-T has resulted in the=20 > >>> agreement to create a Transport Profile for MPLS (MPLS TP). This=20 > >>> effort requires the MPLS, PWE3 and CCAMP Working Groups are=20 > >>> chartered to do the required work. > >>> > >>> The MPLS, PWE3 and CCAMP chairs proposes that we add the=20 > following=20 > >>> paragraph to the three working group charters: > >>> > >>> "- Include extensions to the [MPLS, PWE3, CCAMP]=20 > protocols and RFCs > >>> necessary to fulfill an MPLS Transport Profile=20 > (MPLS TP), the work > >>> on the MPLS TP needs to be coordinated between the=20 > three working > >>> groups (MPLS, PWE3 and CCAMP) that are chartered to=20 > do MPLS TP > >>> work." > >>> > >>> Please send your comments to the working group(s) mailing list(s)=20 > >>> eob Friday May 16. > >>> > >>> Adrian, Deborah, Danny, Stewart, George and Loa > >>> > >>> > >>> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > >> > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.nu >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2008 07:37:02 +0000 Message-ID: <4827F2D3.7030609@pi.nu> Date: Mon, 12 May 2008 09:33:39 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adrian Farrel CC: stbryant@cisco.com, Shahram Davari , 'ccamp' , mpls@ietf.org, 'pwe3' Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, Adrian Farrel wrote: > Hi, > > Perhaps... > OLD > Include extensions to the [MPLS, PWE3, CCAMP] protocols > NEW > Include modifications and extensions to the [MPLS, PWE3, CCAMP] > protocols and procedures my take on this that we are talking about "extensions" relative the the existing specification, it is quite possible for an extension to leave "components of the MPLS architecture unused", that is in fact the case with most of our documents. Consequently I agree with Stewart, and would oppose words like, reduce and modify, since that implies that we intend to *change* the MPLS architecture, while one of the foundations of the agreement to create an MPLS TP was that it should fit into the MPLS architecture. /Loa > > Adrian > > ----- Original Message ----- From: "Stewart Bryant" > To: "Shahram Davari" > Cc: "'ccamp'" ; ; "'pwe3'" > > Sent: Friday, May 09, 2008 9:52 PM > Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work > > >> I think it was fine as it was. We are not going to do and unnecessary >> extensions, and we are not going to remove any functionality that is >> already in there because we need it for other applications. >> >> We could perhaps say: >> >> "Include necessary extensions ...." to make it completely clear. >> >> Stewart >> >> Shahram Davari wrote: >>> Hi Loa, >>> >>> Just a clarification. The term reduction means components of the MPLS >>> architecture left unused. >>> >>> Regards, >>> Shahram >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Shahram Davari >>> Sent: May-09-08 2:52 PM >>> To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' >>> Subject: Re: [mpls] proposed charter update for the MPLS TP work >>> >>> Hi Loa, >>> >>> The term "extension" is not very appropriate. It doesn't cover the >>> possible >>> case of MPLS TP requiring a reduction in MPLS functionality? >>> >>> How about changing that to "extensions and reductions" >>> >>> Regards, >>> -Shahram >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of Loa >>> Andersson >>> Sent: May-09-08 6:57 AM >>> To: ccamp; mpls@ietf.org; pwe3 >>> Subject: [mpls] proposed charter update for the MPLS TP work >>> >>> MPLS, CCAMP and PWE3 working groups, >>> >>> >>> The Joint Working Team of the IETF and ITU-T has resulted in >>> the agreement to create a Transport Profile for MPLS (MPLS TP). >>> This effort requires the MPLS, PWE3 and CCAMP Working Groups >>> are chartered to do the required work. >>> >>> The MPLS, PWE3 and CCAMP chairs proposes that we add the >>> following paragraph to the three working group charters: >>> >>> "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs >>> necessary to fulfill an MPLS Transport Profile (MPLS TP), the work >>> on the MPLS TP needs to be coordinated between the three working >>> groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP >>> work." >>> >>> Please send your comments to the working group(s) mailing list(s) >>> eob Friday May 16. >>> >>> Adrian, Deborah, Danny, Stewart, George and Loa >>> >>> >>> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 May 2008 21:36:31 +0000 Message-ID: <02b601c8b21c$027f3a60$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Shahram Davari" Cc: "'ccamp'" , , "'pwe3'" Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work Date: Fri, 9 May 2008 22:31:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Perhaps... OLD Include extensions to the [MPLS, PWE3, CCAMP] protocols NEW Include modifications and extensions to the [MPLS, PWE3, CCAMP] protocols and procedures Adrian ----- Original Message ----- From: "Stewart Bryant" To: "Shahram Davari" Cc: "'ccamp'" ; ; "'pwe3'" Sent: Friday, May 09, 2008 9:52 PM Subject: Re: [PWE3] [mpls] proposed charter update for the MPLS TP work >I think it was fine as it was. We are not going to do and unnecessary > extensions, and we are not going to remove any functionality that is > already in there because we need it for other applications. > > We could perhaps say: > > "Include necessary extensions ...." to make it completely clear. > > Stewart > > Shahram Davari wrote: >> Hi Loa, >> >> Just a clarification. The term reduction means components of the MPLS >> architecture left unused. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Shahram Davari >> Sent: May-09-08 2:52 PM >> To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' >> Subject: Re: [mpls] proposed charter update for the MPLS TP work >> >> Hi Loa, >> >> The term "extension" is not very appropriate. It doesn't cover the >> possible >> case of MPLS TP requiring a reduction in MPLS functionality? >> >> How about changing that to "extensions and reductions" >> >> Regards, >> -Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Loa >> Andersson >> Sent: May-09-08 6:57 AM >> To: ccamp; mpls@ietf.org; pwe3 >> Subject: [mpls] proposed charter update for the MPLS TP work >> >> MPLS, CCAMP and PWE3 working groups, >> >> >> The Joint Working Team of the IETF and ITU-T has resulted in >> the agreement to create a Transport Profile for MPLS (MPLS TP). >> This effort requires the MPLS, PWE3 and CCAMP Working Groups >> are chartered to do the required work. >> >> The MPLS, PWE3 and CCAMP chairs proposes that we add the >> following paragraph to the three working group charters: >> >> "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs >> necessary to fulfill an MPLS Transport Profile (MPLS TP), the work >> on the MPLS TP needs to be coordinated between the three working >> groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP >> work." >> >> Please send your comments to the working group(s) mailing list(s) >> eob Friday May 16. >> >> Adrian, Deborah, Danny, Stewart, George and Loa >> >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 May 2008 21:23:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 May 2008 17:21:12 -0400 Subject: Re: [mpls] proposed charter update for the MPLS TP work From: George Swallow To: Shahram Davari , "'Loa Andersson'" , "'ccamp'" , , "'pwe3'" Message-ID: Thread-Topic: [mpls] proposed charter update for the MPLS TP work Thread-Index: Acix47OpiyIUe70hTtS1Q5bd3k6JiAAH18bgAAPf2YAAAgI4Sw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2098; t=1210368077; x=1211232077; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:=20George=20Swallow=20 |Subject:=20Re=3A=20[mpls]=20proposed=20charter=20update=20 for=20the=20MPLS=20TP=20work |Sender:=20; bh=Z0OwBvOHgMQQEANh9cC2DSv++1a53eNHp7nczcxbviQ=; b=a1sbWnVIamWVsl7XMEmrT4cbZEGDkLmFvOPGfm9+Sf0w8Bns/j/Ng8mJuV y+QhiO7Aj83XdT6r4QC4bCfB2P1FdzDP7TOK7eQwhTpRE+wmNqAeyk6RKQNN +lnfSPOjVD; Authentication-Results: sj-dkim-2; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); We are not reducing anything in the MPLS architecture and protocols. There will be a few extension. The Transport Profile will define a profile of the MPLS architecture and that is were the reduction comes. ...George On 5/9/08 4:26 PM, "Shahram Davari" wrote: > Hi Loa, > > Just a clarification. The term reduction means components of the MPLS > architecture left unused. > > Regards, > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: May-09-08 2:52 PM > To: 'Loa Andersson'; 'ccamp'; mpls@ietf.org; 'pwe3' > Subject: Re: [mpls] proposed charter update for the MPLS TP work > > Hi Loa, > > The term "extension" is not very appropriate. It doesn't cover the possible > case of MPLS TP requiring a reduction in MPLS functionality? > > How about changing that to "extensions and reductions" > > Regards, > -Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: May-09-08 6:57 AM > To: ccamp; mpls@ietf.org; pwe3 > Subject: [mpls] proposed charter update for the MPLS TP work > > MPLS, CCAMP and PWE3 working groups, > > > The Joint Working Team of the IETF and ITU-T has resulted in > the agreement to create a Transport Profile for MPLS (MPLS TP). > This effort requires the MPLS, PWE3 and CCAMP Working Groups > are chartered to do the required work. > > The MPLS, PWE3 and CCAMP chairs proposes that we add the > following paragraph to the three working group charters: > > "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs > necessary to fulfill an MPLS Transport Profile (MPLS TP), the work > on the MPLS TP needs to be coordinated between the three working > groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP > work." > > Please send your comments to the working group(s) mailing list(s) > eob Friday May 16. > > Adrian, Deborah, Danny, Stewart, George and Loa > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 May 2008 15:56:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: proposed charter update for the MPLS TP work Date: Fri, 9 May 2008 17:53:19 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83D0EEED@DEMUEXC014.nsn-intra.net> Thread-Topic: proposed charter update for the MPLS TP work Thread-Index: AcixxZ/4OD/celZWRyO83Uds8ojh7AAJxiSg From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Loa Andersson" , "ccamp" , , "pwe3" I support the extension in the charters of the three WGs.=20 Best regards, Nurit -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Loa Andersson Sent: Friday, May 09, 2008 13:57 To: ccamp; mpls@ietf.org; pwe3 Subject: proposed charter update for the MPLS TP work MPLS, CCAMP and PWE3 working groups, The Joint Working Team of the IETF and ITU-T has resulted in the agreement to create a Transport Profile for MPLS (MPLS TP). This effort requires the MPLS, PWE3 and CCAMP Working Groups are chartered to do the required work. The MPLS, PWE3 and CCAMP chairs proposes that we add the following paragraph to the three working group charters: "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs necessary to fulfill an MPLS Transport Profile (MPLS TP), the work on the MPLS TP needs to be coordinated between the three working groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP work." Please send your comments to the working group(s) mailing list(s) eob Friday May 16. Adrian, Deborah, Danny, Stewart, George and Loa --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 May 2008 10:59:44 +0000 Message-ID: <48242DED.5090403@pi.nu> Date: Fri, 09 May 2008 12:56:45 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ccamp , mpls@ietf.org, pwe3 Subject: proposed charter update for the MPLS TP work Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit MPLS, CCAMP and PWE3 working groups, The Joint Working Team of the IETF and ITU-T has resulted in the agreement to create a Transport Profile for MPLS (MPLS TP). This effort requires the MPLS, PWE3 and CCAMP Working Groups are chartered to do the required work. The MPLS, PWE3 and CCAMP chairs proposes that we add the following paragraph to the three working group charters: "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs necessary to fulfill an MPLS Transport Profile (MPLS TP), the work on the MPLS TP needs to be coordinated between the three working groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP work." Please send your comments to the working group(s) mailing list(s) eob Friday May 16. Adrian, Deborah, Danny, Stewart, George and Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 May 2008 00:06:06 +0000 Message-ID: <482393EA.4090404@lab.ntt.co.jp> Date: Fri, 09 May 2008 08:59:38 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I support both. Those are important docs. Sorry for being late. Kohei > CCAMP, > > From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah -- Kohei Shiomoto, Ph.D NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 3787 Free online contents of "NTT Technical Review" available at https://www.ntt-review.jp/ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2008 18:45:42 +0000 Message-ID: <4821F870.8050105@science.uva.nl> Date: Wed, 07 May 2008 20:44:00 +0200 From: Freek Dijkstra Organization: Universiteit van Amsterdam User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Network modeling & NML group in the OGF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I got some off-list replies. Let me elaborate a bit. The network markup language (NML) working group in the OGF -in my view- seems focussed on network descriptions for multi-domain scenarios. In those scenarios loose coupling and extensions to refer to other resources are important. GMPLS seems mostly focussed on a control plane within a single administrative domain. Nevertheless, I see overlap. I imagine a future where GMPLS is used within a single administrative domain, that data is extracted and in abstracted form announced to select partners for multi-domain lightpath provisioning. Such a tool would be a lot easier if there was a common network model. Translating between two syntaxes is easy. Translating between two models is very hard. In an ideal world, every technology uses the same model, so conversion is easy. We don't live in an ideal world. For example, GMPLS does NOT follow G.805 and G.8080. To give two examples: Fundamental concepts in GMPLS are labels and capacity (bandwidth). Neither of these concept is is present in G.805. In GMPLS, there is no 1:1 relation between encapsulation "layers" and switching capability "layers". In GMPLS, there is (link connections and subnetwork connections are on the same layer network). Because of this difference in model, it is hard to convert from a set of TLV in OSPF-TE and a network description in G.805 functional elements or vice versa. What I would hope for the NML working group is to learn as much as possible from all these different models, and decide on one which is most usable for all, and is easy to convert to other models and syntaxes. Clearly, G.805 and G.8080 are input, but they are not complete (*). The model (if any) used in GMPLS is another input, and I am seeking that input from this list. Regards, Freek (*) For example, we like to add time-based information to track changes in the network topology. We like the label and switching capability concepts in GMPLs, neither of which is in G.805 or G.8080. Also you don't want to know how many people assume that a device interface maps to a single G.805 "connection point" -- that is not true, since a device interface is a physical interface, which may map to multiple logical interfaces, one for each layer. These things need to be specified. PS: It was perhaps not completely clear in my previous mail. We (the developers of the network description language, NDL) use RDF. However that this is not always true for everyone in the Network markup language (NML) working group in the OGF. Most of the other partners prefer to use XML for example. We decided to simply come up with a common model in UML, and allow multiple syntaxes. Again, if there is a common model, translating between syntaxes is trivial. That common model is the hard part. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2008 16:25:27 +0000 Message-ID: <4821D76A.1000805@grotto-networking.com> Date: Wed, 07 May 2008 09:23:06 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Giovanni Martinelli CC: "BRUNGARD, DEBORAH A, ATTLABS" , ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the good comments Giovanni, we'll incorporate them into the next revision. Also see below. Greg B. Giovanni Martinelli wrote: > Hi, > > yes support both > > I have also few comments on Framework WSON > > - Section 3.3.1 > How about using a more generic OXC model? Or may be having a two > pictures, one with the current ROADM and one with an OXC (degree > > 2)? For sure the simple ROADM it's the easier to understand but looks > to me too specific. --> We've (authors of the WSON info model draft) have been discussing these issues lately. So we'll be sure to make this more generic in at least one of the drafts (if not both). > > > The text: "As the degree of the ROADM increases beyond two it can have > properties of both a switch(OXC)and a multiplexer" > To me looks like the figure 1 has already multiplexing capability > correct? For example a wavelength entering in what you call an add > port is multiplexed on a *line* (keeping same terminology of the > document) port. > > A simple questions on the switching matrix: looks like add/drop ports > and *line* ports are considered the same in the matrix, correct? --> Yes. The difference between port types is given by the per port wavelength constraints. We are currently trying to make this a bit more rigorous. > > - Section 4.1 > About time frame classification: Dynamic, pseudo-static and static. > While the text explains why an RWA would appreciate some temporal > information a classification like "relatively short" or "moderately > long" are a bit difficult to understand to me, Long or short are > compared to what?. --> We'll fix this and/or remove it. Others share you concerns including the WG chairs. > > - Section 6 Security > Does it worth a reference to > http://tools.ietf.org/id/draft-fang-mpls-gmpls-security-framework-01.txt? --> Yes. > > - A small ed note: in reference section the [G.994.1] is within both > normative and informative sub-sections... --> All my fault. Will Fix. > > Cheers > G > > > > > > > BRUNGARD, DEBORAH A, ATTLABS wrote: >> CCAMP, >> >> From Philadelphia, we had good support for adoption of two of the >> WSON documents as CCAMP working group documents: >> >> - Framework for WSON >> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt >> >> >> - Lambda Labels >> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt >> >> >> Please express your opinions (authors, we welcome your opinion also). >> >> Thanks, >> Adrian and Deborah > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2008 14:52:14 +0000 Message-ID: <4821C193.9050806@science.uva.nl> Date: Wed, 07 May 2008 16:49:55 +0200 From: Freek Dijkstra Organization: Universiteit van Amsterdam User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Network modeling & NML group in the OGF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi folks, I've was recently pointed to the WSON list by a colleague, who is liaison of the Open Grid Forum (OGF) towards the IETF [1]. The list has no archive, so I may have missed a few topics, but after reading the discussion on the difference between OOO and OEO or on wavelength versus waveband switching, I think there is a need for an explicit multilayer model. The MLN/MRN work at least has a syntax, but I have not seen a formal model. I'll post this to the CCAMP list rather than the WSON list since it is a bit more general. I just finished my PhD thesis on multi-layer path finding. I'll briefly mention this work (I apologize for the shameless plug) and than mention was is currently done in the OGF. Let's see if there is some mutual interest. We created a model and syntax called Network Description Language (NDL) [2]. A major goal was to enable complex multi-layer path finding, with a technology independent algorithm. "Complex" because multi-layer path can in fact contain loops [3], which is not possible in single layer networks. The technology independence (no technology-specific code) means that not only the networks are described in an abstract model, but so are the different technologies. For example, the path finding "learns" about characteristics of WDM by reading a file describing the technology. That file contains the different adaptations, layers and label definition (in our WDM example file, the labels are floats: the wavelength in nm, and the spacings are described as different adaptations. Interestingly it is possible to use the same model to make another technology description of WDM, for example with or without a group mux sublayer). Of course the challenge was to force the different technologies in such a generic model. Tagged Ethernet in particular took some effort. One thing that worked very well was to distinguish between two different switching capabilities: one "switching" for forwarding traffic with the same "label" (e.g. wavelength switching without wavelength conversion or Ethernet VLANs) and for forwarding while allowing label changes (e.g. timeslots in TDM or wavelength conversion). Beside the model, we create a syntax. Instead, our syntax is based on semantic web [4] and RDF. What worked very well was that we could easily separate the different subtopics: topologies description, (technology) layers, capabilities (such as the ability or inability of a device to convert between labels), domain abstraction, physical properties, etc. What's more, we could easily combine this information with different information such as policy descriptions and pointers to reservation systems. We are in the process of combining network description with a description of 4K very high definition digital cinema display, media and storage) [5], so that a metascheduler not only can take network resources but also storage and visualization resources into account. In case you wonder how our model compares with GMPLS: Jeroen van der Ham, a fellow PhD student, just wrote an interface to convert between our description and OSPF-TE. This was done in collaboration with Max Gigapop, a research network that also developed DRAGON, a free GMPLS implementation [6]). Our work is developed and in limited use in a community of national research networks called the GLIF [7], which provides circuit-switched network connection for e-science applications around the globe. ("limited" since it is restricted to a single layer for now). As for the relation with GMPLS: our model is based on functional elements as described in ITU-T G.805 [8], combined with the label concept in GMPLS. That is generic and powerful enough to describe and find paths in WDM, TDM, Ethernet and fiber switch networks [9]. So much for our model and the shameless plug. The reason I mention all this is that we are of course not the only ones to create a syntax to describe networks. OSPF-TE is an obvious other one. There are quite a few research projects which also create their own syntax. Some use GMPLS, though most that involve multi-layer networks create their own model and syntax. About a year ago, some of these groups joined forces to standardize on a network description. The Open Grid Forum (OGF) [1], a standardization body originally active in standardization of Grid software, has a working group, called Network Markup Language (NML), which does exactly such multi-layer network modelling [10]. Active members are us, developers of the PerfSONAR measurement software, and miscellaneous partners in GÉANT (European research network) projects. Each of these active members brings their own multi-layer models, each with each strengths and weaknesses. Clearly there is some overlap with CCAMP here. Of course, there are difference as well. The NML working groups mostly is concerned with multi-domain descriptions, and the interactions needed there. Thus, the ability to describe an abstracted view of the network, with capability information, pointers to services for policy decision and policy enforcement points, etc. Typical projects I see are research projects that provide dedicated network connections (either using Ethernet, DWDM, or TDM) through a collaboration of 5-20 network domains, each using their own inter-domain control plane software. Typical control planes I see are DRAGON, UCLP, G-Lambda, DRAC, AutoBAHN, etc. If you are interested, I gladly elaborate on either our model, the path finding, or the working group. Perhaps it would be could that we can share some of our use cases, requirements and solutions, while you some of the active members here could provide the NML working group with input from the CCAMP group. With kind regards, Freek Dijkstra [1] OGF http://www.ogf.org/ [2] Network Description Language, http://www.science.uva.nl/research/sne/ndl/ [3] Loop example in multi layer networks http://staff.science.uva.nl/~fdijkstr/presentations/Going-in-Loops.pdf (poster) or http://staff.science.uva.nl/~fdijkstr/publications/ndl-pathfinding.pdf (short article) [4] Semantic web, http://www.w3.org/2001/sw/ [5] 4k digital cinema, http://www.cinegrid.org/ [6] DRAGON, http://dragon.maxgigapop.net/ [7] GLIF community, http://www.glif.is/ [8] ITU-T G.805, http://www.itu.int/rec/T-REC-G.805/ [9] Technology descriptions in NDL, http://www.science.uva.nl/research/sne/ndl/?c=01-Schemas [10] NML-WG, https://forge.gridforum.org/sf/projects/nml-wg https://forge.gridforum.org/sf/projects/nml-wg Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2008 12:13:26 +0000 Message-ID: <48219BF8.4060401@cisco.com> Date: Wed, 07 May 2008 14:09:28 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1909; t=1210162197; x=1211026197; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20Poll=20for=20WG=20Adoption=20of=20Two=2 0WSON=20documents |Sender:=20; bh=FftzsA+9oUttzcQPP1TfRabbOOCrdyAQBoV3ZCedr7E=; b=CrPDgDDLmNGwiFdrUdt9NAhzo7u8KQzN79Ag7b1ZiuJQLJjJbSyCXjoKFy e0DEPwqpbzn8s5/v3Q0gF3fw7jjL6w5OUyNTEXMyV9JuNI5x0cNh4cT54J0C snb6Buaypw; Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Hi, yes support both I have also few comments on Framework WSON - Section 3.3.1 How about using a more generic OXC model? Or may be having a two pictures, one with the current ROADM and one with an OXC (degree > 2)? For sure the simple ROADM it's the easier to understand but looks to me too specific. The text: "As the degree of the ROADM increases beyond two it can have properties of both a switch(OXC)and a multiplexer" To me looks like the figure 1 has already multiplexing capability correct? For example a wavelength entering in what you call an add port is multiplexed on a *line* (keeping same terminology of the document) port. A simple questions on the switching matrix: looks like add/drop ports and *line* ports are considered the same in the matrix, correct? - Section 4.1 About time frame classification: Dynamic, pseudo-static and static. While the text explains why an RWA would appreciate some temporal information a classification like "relatively short" or "moderately long" are a bit difficult to understand to me, Long or short are compared to what?. - Section 6 Security Does it worth a reference to http://tools.ietf.org/id/draft-fang-mpls-gmpls-security-framework-01.txt? - A small ed note: in reference section the [G.994.1] is within both normative and informative sub-sections... Cheers G BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 May 2008 21:03:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AFBC.3C892B14" Subject: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Date: Tue, 6 May 2008 16:00:37 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF1112CF11@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Working Group Last Call: draft-ietf-ccamp-gr-description-02 Thread-Index: AcivvDwYh3PM2WbnQICkg9X3bgptaA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AFBC.3C892B14 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable CCAMP, =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.t xt =20 Please send your comments to the mailing list prior to EOB May 20. =20 Adrian and Deborah ------_=_NextPart_001_01C8AFBC.3C892B14 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
This is to=20 initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-descri= ption-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 20.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AFBC.3C892B14-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 May 2008 02:02:48 +0000 Date: Tue, 06 May 2008 10:00:07 +0800 From: Dan Li Subject: Fw: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt To: ccamp Cc: "Bardalai, Snigdho" , Arun Satyanarayana , "Gao, Jianhua" Message-id: <074101c8af1c$e88cdd30$3d4d460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_b7CfSTLsUDbjz3btt4K27w)" This is a multi-part message in MIME format. --Boundary_(ID_b7CfSTLsUDbjz3btt4K27w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear CCAMPers, We just updated the GR-Description draft, there is no technical change in this version. We added some text to clarify the procedures for multi nodes which are not neighbors restart scenario. Best regards, Dan ----- Original Message ----- From: To: Cc: Sent: Tuesday, May 06, 2008 6:45 AM Subject: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Description of the RSVP-TE Graceful Restart Procedures > Author(s) : D. Li > Filename : draft-ietf-ccamp-gr-description-02.txt > Pages : 17 > Date : 2008-5-5 > > The Hello message for the Resource Reservation Protocol (RSVP) has > been defined to establish and maintain basic signaling node > adjacencies for Label Switching Routers (LSRs) participating in a > Multiprotocol Label Switching (MPLS) traffic engineered (TE) > network. The Hello message has been extended for use in Generalized > MPLS (GMPLS) network for state recovery of control channel or nodal > faults. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > --Boundary_(ID_b7CfSTLsUDbjz3btt4K27w) Content-type: text/plain; name=draft-ietf-ccamp-gr-description-02.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-ccamp-gr-description-02.txt Content-Type: text/plain Content-ID: <2008-5-5153926.I-D@ietf.org> --Boundary_(ID_b7CfSTLsUDbjz3btt4K27w)-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 May 2008 22:48:05 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080505224502.2AEC33A68A5@core3.amsl.com> Date: Mon, 5 May 2008 15:45:02 -0700 (PDT) --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 : Description of the RSVP-TE Graceful Restart Procedures Author(s) : D. Li Filename : draft-ietf-ccamp-gr-description-02.txt Pages : 17 Date : 2008-5-5 The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gr-description-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-5153926.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 May 2008 22:34:06 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-09.txt Message-Id: <20080501221501.55B983A6D2F@core3.amsl.com> Date: Thu, 1 May 2008 15:15:01 -0700 (PDT) --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 : Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Author(s) : K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro Filename : draft-ietf-ccamp-gmpls-mln-reqs-09.txt Pages : 25 Date : 2008-5-1 Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-reqs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-1151318.I-D@ietf.org> --NextPart--