From owner-ccamp@ops.ietf.org Sat Oct 4 12:05:06 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 864F53A6A53 for ; Sat, 4 Oct 2008 12:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_05=-1.11, 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 codT-5Qe8LLP for ; Sat, 4 Oct 2008 12:05:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC5F43A6834 for ; Sat, 4 Oct 2008 12:05:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmCJT-000N7V-1B for ccamp-data@psg.com; Sat, 04 Oct 2008 18:57:11 +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 1KmCJO-000N6c-Ch for ccamp@ops.ietf.org; Sat, 04 Oct 2008 18:57:09 +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 m94Iv4Db027616 for ; Sat, 4 Oct 2008 19:57:04 +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 m94Iv2BZ027602 for ; Sat, 4 Oct 2008 19:57:04 +0100 Message-ID: <043d01c92652$fdcdb360$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: RFC 5305 on IS-IS Extensions for Traffic Engineering Date: Sat, 4 Oct 2008 19:50:37 +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.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi CCAMP, Be aware... > A new Request for Comments is now available in online RFC libraries. > RFC 5305 > Title: IS-IS Extensions for Traffic Engineering > URL: http://www.rfc-editor.org/rfc/rfc5305.txt This obsoletes RFC 3784 but the only change is to move the work onto the standards track. Adrian From a20092008@gmail.com Sat Oct 4 22:53:02 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 74D643A68CB for ; Sat, 4 Oct 2008 22:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.826 X-Spam-Level: *** X-Spam-Status: No, score=3.826 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] 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 N3NF-2L4WDjr for ; Sat, 4 Oct 2008 22:53:01 -0700 (PDT) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id AD6A03A6826 for ; Sat, 4 Oct 2008 22:53:01 -0700 (PDT) Received: from coloso ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0K8900KZ34CSEXA0@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Sun, 05 Oct 2008 02:53:17 -0300 (ART) Date: Sun, 05 Oct 2008 02:53:40 -0300 From: "a20092008@gmail.com" Subject: COMPUTADORA ATHLON COMPLETA To: PCs Errors-to: a200982008_@gmail.com Message-id: <3817-22008100555339895@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: a20092008@gmail=2Ecom CEL: 15-3197-5821 -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco r=EDgido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 =BD=2E -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y util= idades -$1049 IVA Incluido Consulte por otras configuracion y otros productos, monitores LCD, noteboo= ks, etc From owner-ccamp@ops.ietf.org Mon Oct 13 05:20:24 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 EFBBC3A68D2 for ; Mon, 13 Oct 2008 05:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 ndTvZFHs5mt1 for ; Mon, 13 Oct 2008 05:20:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17BAE3A6883 for ; Mon, 13 Oct 2008 05:20:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpMIr-000LjI-TQ for ccamp-data@psg.com; Mon, 13 Oct 2008 12:13:37 +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 1KpMIj-000LiQ-KU for ccamp@ops.ietf.org; Mon, 13 Oct 2008 12:13:35 +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 m9DCDQdD019853 for ; Mon, 13 Oct 2008 13:13:26 +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 m9DCDP1T019830 for ; Mon, 13 Oct 2008 13:13:25 +0100 Message-ID: <002701c92d2d$173f9170$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison Received from ITU "GMPLS signaling for VCAT/LCAS (09/2008)" Date: Mon, 13 Oct 2008 13:10:41 +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.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, We have received a liaison from the Interregnum Meeting of Questions 12 and 14 of Study Group 15 of the ITU-T. The text of the liaison is as follows... > Thank you for your liaison statement on GMPLS control of VCAT/LCAS dated > September 5, 2008. We also thank Mr. Farrel for presenting the liaison > statement at our Beijing Interregnum meeting. > > At the moment we don't have comment on the -05 version of the GMPLS > VCAT/LCAS I-D (draft-ietf-ccamp-gmpls-vcat-lcas). We are looking > forward to text in future version of the I-D to clarify, as indicated in > your > response, that there are different name (or identifier) spaces even though > they may all use the same IP address format. As with all incoming and outgoing communications, you can find this liaison through the alternative CCAMP pages at www.olddog.co.uk/ccamp.htm Adrian From owner-ccamp@ops.ietf.org Mon Oct 13 05:51: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 A7C143A693D for ; Mon, 13 Oct 2008 05:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.278 X-Spam-Level: X-Spam-Status: No, score=0.278 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_20=-0.74, 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 RU63mamXnGYg for ; Mon, 13 Oct 2008 05:51:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96E003A6846 for ; Mon, 13 Oct 2008 05:51:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpMog-000PIe-Ib for ccamp-data@psg.com; Mon, 13 Oct 2008 12:46:30 +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 1KpMoa-000PGQ-EB for ccamp@ops.ietf.org; Mon, 13 Oct 2008 12:46: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 m9DCDQQe019872 for ; Mon, 13 Oct 2008 13:13:26 +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 m9DCDP1V019830 for ; Mon, 13 Oct 2008 13:13:26 +0100 Message-ID: <002801c92d2d$17896bb0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison from the ITU "WSON work in Q12/15" Date: Mon, 13 Oct 2008 13:13:17 +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.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, We have received a liaison from the Interregnum Meeting of Questions 12 and 14 of Study Group 15 of the ITU-T. The text of the liaison is as follows... > Thank you for your liaison statement of September 6, 2008 to Q3/15 > regarding the OTN work plan advising us of your work on Wavelength > Switched Optical Networks (WSON). > > Q.12/15 has initiated work on developing a network model for WSON, > we will be working in cooperation with Q6/15 to include optical > impairments > in this model. One intended output of this work is a model that can be > used > for path computation in the presence of both optical impairments and > blocking > switches. We note that the aspects related to optical impairments are > quite > challenging and we are engaging the appropriate experts. In view of this > we > would encourage you to continue your focus on networks in which > impairments > can be neglected and only wavelength assignment needs to be considered. > > We noted that you are considering the use of a matrix to represent the > blocking > characteristics of an asymmetrical switch (e.g. ROADM). We are > considering > the use of a bipartite graph since it appears to be suitable for path > computation. > > We will review the internet drafts that you reference and would be obliged > if > you kept us informed of your progress on work in this area. As with all incoming and outgoing communications, you can find this liaison through the alternative CCAMP pages at www.olddog.co.uk/ccamp.htm Adrian From yhhangle@travelocity.com Mon Oct 13 20:22: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 A83E53A6B78; Mon, 13 Oct 2008 20:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.221 X-Spam-Level: X-Spam-Status: No, score=-87.221 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_MISMATCH_COM=0.553, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, 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 kZC4EG8Ri9mv; Mon, 13 Oct 2008 20:22:01 -0700 (PDT) Received: from travelocity.com (cda182.neoplus.adsl.tpnet.pl [83.30.150.182]) by core3.amsl.com (Postfix) with SMTP id AF9113A6BA0; Mon, 13 Oct 2008 20:21:59 -0700 (PDT) Received: from basia5eru6b51e ([67.138.194.43] helo=basia5eru6b51e) by b6961e53travelocity.com (8.11.6/8.11.6) with SMTP id 579171293A71 for ; Tue, 14 Oct 2008 05:22:57 +0200 Message-ID: <001401c92dbc$eaa20cc0$069b463c@basia5eru6b51e> From: annex in To: ccamp-archive@ietf.org Subject: He evident Date: Tue, 14 Oct 2008 05:22:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C92DBC.EAA20CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.2969 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C92DBC.EAA20CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable substitute for the drugs I've never done though overloads do trying to live an interesting life, doing what they want to do, valuable commodity information that will keep them ahead of the ------=_NextPart_000_0011_01C92DBC.EAA20CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
science. Ad agencies are cashing in on its' commerciality and

C A eN A DuAN     P r oH A RM A uCY

VsA mG _RA - $1.46
C 4c A L v S - $2.21
S0 O M A - $0.69
L E6 V e T R A - $3.61
FoEMALE mVv2A9G0R2A - $1.50
U w L T cR A M - $1.33
 

interesting; however, the finished work of art still depends on
= ------=_NextPart_000_0011_01C92DBC.EAA20CC0-- From owner-ccamp@ops.ietf.org Wed Oct 15 14:50: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 2BF0E3A687A for ; Wed, 15 Oct 2008 14:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.397, 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 Vfb4HwfYCEOv for ; Wed, 15 Oct 2008 14:50:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D8453A67FC for ; Wed, 15 Oct 2008 14:50:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqEC4-0003M6-Lv for ccamp-data@psg.com; Wed, 15 Oct 2008 21:46:12 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqEBv-0003LP-JX for ccamp@ops.ietf.org; Wed, 15 Oct 2008 21:46:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id AD55D3A6A76; Wed, 15 Oct 2008 14: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-lsp-hierarchy-bis-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081015214501.AD55D3A6A76@core3.amsl.com> Date: Wed, 15 Oct 2008 14:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-04.txt Pages : 28 Date : 2008-10-15 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle.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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-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-lsp-hierarchy-bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-15143443.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Fri Oct 17 15:05: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 E5D8428C12F for ; Fri, 17 Oct 2008 15:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 aOSmZrxksuvs for ; Fri, 17 Oct 2008 15:05:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFFDA3A6A22 for ; Fri, 17 Oct 2008 15:05:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqxNl-0000x8-52 for ccamp-data@psg.com; Fri, 17 Oct 2008 22:01:17 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqxNb-0000wN-Mb for ccamp@ops.ietf.org; Fri, 17 Oct 2008 22:01:13 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3979A3A6AFE; Fri, 17 Oct 2008 15: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-lsp-hierarchy-bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081017220001.3979A3A6AFE@core3.amsl.com> Date: Fri, 17 Oct 2008 15:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, A. Farrel, R. Rabbat, A. Ayyangar, Z. Ali Filename : draft-ietf-ccamp-lsp-hierarchy-bis-05.txt Pages : 28 Date : 2008-10-17 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-05.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-lsp-hierarchy-bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-17144849.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Oct 20 20:09: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 523363A697B for ; Mon, 20 Oct 2008 20:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[AWL=-1.618, 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 1K+ICGVgXHP2 for ; Mon, 20 Oct 2008 20:09:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82E0B3A69D1 for ; Mon, 20 Oct 2008 20:09:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ks7T7-0003Dk-OO for ccamp-data@psg.com; Tue, 21 Oct 2008 02:59:37 +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 1Ks7S6-00039i-Tt for ccamp@ops.ietf.org; Tue, 21 Oct 2008 02:58:37 +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 m9L2wTbL013742 for ; Tue, 21 Oct 2008 03:58:31 +0100 Received: from your029b8cecfe ([38.109.153.132]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m9L2wRbq013735 for ; Tue, 21 Oct 2008 03:58:28 +0100 Message-ID: <02f801c93328$e43a3c60$84996d26@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Call for agenda slot requests Date: Tue, 21 Oct 2008 03:58:24 +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.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, Please let us know if you would like some time on the CCAMP agenda in Minneapolis. Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Tue Oct 21 08:47: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 03FC23A67C0 for ; Tue, 21 Oct 2008 08:47:33 -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 L0Y3g9h9jbVB for ; Tue, 21 Oct 2008 08:47:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23A4F3A6B41 for ; Tue, 21 Oct 2008 08:47:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsJMY-00008g-Gi for ccamp-data@psg.com; Tue, 21 Oct 2008 15:41:38 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsJMR-00007r-QL for ccamp@ops.ietf.org; Tue, 21 Oct 2008 15:41:34 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id m9LFfFxh059610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 08:41:17 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <48FDF81E.3060802@grotto-networking.com> Date: Tue, 21 Oct 2008 08:41:18 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Call for agenda slot requests References: <02f801c93328$e43a3c60$84996d26@your029b8cecfe> In-Reply-To: <02f801c93328$e43a3c60$84996d26@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian, here's what I know on the WSON front (that doesn't mean that I'll present all this stuff ;-)). Working group documents: (a) Update on the WSON Framework document - Pierre (Alcatel) and Dirk (Cisco) are helping to get this better organized and add application scenarios. I'd probably present - 5 minutes or less (b) Update on the WSON RWA info model - 5 minutes or less -- Not yet working group documents: (c) Update on RWA info model Encoding - 5 minutes or less. (d) Update on WSON signaling -- Some new work/applications extensions we'd like to go over (5 minutes). -- New work (impairment related, these will probably motivate discussion) -- (e) WSON Impairment Framework draft -- This is new work where we look at how the control plane and optical impairments work together and what could fall within the CCAMP (and PCE) charters. (f) WSON Impairment Validation Information Model -- Here we take a first attempt at taking an ITU-T network element centric impairment model and adapting it for use in the control plane. Regards Greg Adrian Farrel wrote: > Hi, > > Please let us know if you would like some time on the CCAMP agenda in > Minneapolis. > > Thanks, > Adrian and Deborah > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From owner-ccamp@ops.ietf.org Thu Oct 23 16:43: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 6587B3A67EE for ; Thu, 23 Oct 2008 16:43:33 -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 ukvRGJ9e7aXX for ; Thu, 23 Oct 2008 16:43:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DBC03A68B3 for ; Thu, 23 Oct 2008 16:43:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt9lO-0008b7-HU for ccamp-data@psg.com; Thu, 23 Oct 2008 23:38:46 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt9lH-0008aj-BZ for ccamp@ops.ietf.org; Thu, 23 Oct 2008 23:38:42 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 7A1D83A6A8F; Thu, 23 Oct 2008 16:37:17 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-ccamp-asymm-bw-bidir-lsps (GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)) to Experimental RFC Reply-to: ietf@ietf.org CC: Message-Id: <20081023233717.7A1D83A6A8F@core3.amsl.com> Date: Thu, 23 Oct 2008 16:37:17 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17127&rfc_flag=0 From owner-ccamp@ops.ietf.org Fri Oct 24 09:13:03 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 5E60728C20F for ; Fri, 24 Oct 2008 09:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-0.424, 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 YsjYWD+UOULs for ; Fri, 24 Oct 2008 09:13:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6ECB43A6995 for ; Fri, 24 Oct 2008 09:13:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KtPCD-0005gj-ES for ccamp-data@psg.com; Fri, 24 Oct 2008 16:07:29 +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 1KtPBz-0005fb-SY for ccamp@ops.ietf.org; Fri, 24 Oct 2008 16:07:21 +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 m9OG7DDx007231 for ; Fri, 24 Oct 2008 17:07:13 +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 m9OG7AYM007185 for ; Fri, 24 Oct 2008 17:07:12 +0100 Message-ID: <002901c935f2$92f928d0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: A BNF specification for RSVP-GMPLS and LMP Date: Fri, 24 Oct 2008 17:05: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.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, This draft provides a specification of the BNF we already use in RSVP-TE and LMP and makes it available for use in future protocol extensions. I intend asking that this draft progress in the standards process relatively soon. Please review and comment as soon as possible. Thanks, Adrian ----- Original Message ----- From: To: Sent: Friday, October 24, 2008 5:00 PM Subject: I-D Action:draft-farrel-rtg-common-bnf-06.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Reduced Backus-Naur Form (RBNF) A Syntax Used in Various > Protocol Specifications > Author(s) : A. Farrel > Filename : draft-farrel-rtg-common-bnf-06.txt > Pages : 12 > Date : 2008-10-24 > > Several protocols have been specified using a common variant of the > Backus-Naur Form (BNF) of representing message syntax. However, there > is no formal definition of this version of BNF. > > There is value in using the same variant of BNF for the set of > protocols that are commonly used together. This reduces confusion and > simplifies implementation. > > Updating existing documents to use some other variant of BNF that is > already formally documented would be a substantial piece of work. > > This document provides a formal definition of the variant of BNF that > has been used (that we call Reduced BNF), and makes it available for > use by new protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-06.txt From n21102008@gmail.com Sat Oct 25 05:38: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 B56A928C1AB for ; Sat, 25 Oct 2008 05:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.122 X-Spam-Level: ** X-Spam-Status: No, score=2.122 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, SUBJ_ALL_CAPS=2.077] 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 Zmqyb7G3DvtP for ; Sat, 25 Oct 2008 05:38:52 -0700 (PDT) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id E83AA3A69D8 for ; Sat, 25 Oct 2008 05:38:51 -0700 (PDT) Received: from f3t ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0K9A00A57OHAWW60@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Sat, 25 Oct 2008 09:39:11 -0300 (ART) Date: Sat, 25 Oct 2008 10:39:16 +0200 From: "n21102008@gmail.com" Subject: SOLO POR HOY To: solo por hoy Message-id: <380-220081062583916406@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable SOLO POR HOY NOTEBOOKS con GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL = FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS EMail: n21102008@gmail=2Ecom CEL: 15-3197-5821 NOTEBOOKS CON DISPONIBILIDAD INMEDIATA DELL VOSTRO 1000 Procesador AMD Turion TL-60 2=2E0GHz Memoria 2GB DDR2 at 667MHz Disco Rigido 120GB SATA Hard Drive (5400RPM) Regrabadora de DVD+/-RW Pantalla 15=2E4 pulgadas WXGA Wireless WIFI Windows Vista Home en Espa=F1ol Color Negro Teclado en Espa=F1ol Precio: $2650 Hewlett Packard Pavilion dv2910us Pantalla 14=2E1" Widescreen Procesador Intel Core 2 Duo T5550 Disco Rigido 250GB Memoria 3GB DDR2 Regrabadora de DVDs and CDs Built-in wireless 802=2E11agn, Built-in webcam=20 Precio: $3800 Toshiba Satellite M305D-S4829 Pantalla 14=2E1" Widescreen CPU AMD Turion 64 DUAL CORE X2 RM-70 2GHz x 2 NUCLEOS Memoria 4GB DDR2 Disco de 250GB Regrabadora de DVDs and CDs Built-in 802=2E11bgn wireless, Built-in webcam y microfono Precio: $3700 Hewlett Packard Pavilion dv6810us Procesador AMD Turion 64 X2 Dual-Core TL-60 2GHz Memoria 3GB (1x2GB, 1x1GB) Disco Rigidos 160GB SATA HD SuperMulti DVD Burner w/ LightScribe Placa de VIDEO nVIDIA GeForce Go 7150M Pantalla 15=2E4" 802=2E11b/g Wi-Fi Bluetooth WVHP Precio: $3200 From owner-ccamp@ops.ietf.org Mon Oct 27 01:13: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 E85DE28C16B for ; Mon, 27 Oct 2008 01:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.016 X-Spam-Level: **** X-Spam-Status: No, score=4.016 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MANGLED_EXTNSN=2.3, 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 yFrbUh67aiCo for ; Mon, 27 Oct 2008 01:13:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15ED728C160 for ; Mon, 27 Oct 2008 01:13:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuN5z-000Ljy-5b for ccamp-data@psg.com; Mon, 27 Oct 2008 08:05:03 +0000 Received: from [62.23.212.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuN5t-000Lj5-8d for ccamp@ops.ietf.org; Mon, 27 Oct 2008 08:05:00 +0000 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m9R84pgZ011941 for ; Mon, 27 Oct 2008 09:04:53 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 27 Oct 2008 09:04:52 +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: MRN ext. doc Date: Mon, 27 Oct 2008 09:04:51 +0100 Message-ID: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MRN ext. doc Thread-Index: Ack4CrAqo5CZmc7IQr24kAGxU45t6w== From: "PAPADIMITRIOU Dimitri" To: X-OriginalArrivalTime: 27 Oct 2008 08:04:52.0467 (UTC) FILETIME=[B0D9EC30:01C9380A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: folks -=20 before asking for LC, we plan an update of this doc. see:=20 please let us know if you see any missing description/holes in this version (beside its IANA section). thx, -d. From owner-ccamp@ops.ietf.org Mon Oct 27 05:52:24 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 0C0293A68DD for ; Mon, 27 Oct 2008 05:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.290, 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 mhzUXnfI6j-r for ; Mon, 27 Oct 2008 05:52:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 151BC3A6816 for ; Mon, 27 Oct 2008 05:52:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuRTM-000Ixg-9o for ccamp-data@psg.com; Mon, 27 Oct 2008 12:45:28 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuRSx-000IvI-Eg for ccamp@ops.ietf.org; Mon, 27 Oct 2008 12:45:07 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 0AC823A6A4E; Mon, 27 Oct 2008 05: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-gmpls-ethernet-arch-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027124502.0AC823A6A4E@core3.amsl.com> Date: Mon, 27 Oct 2008 05:45:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Pages : 20 Date : 2008-10-27 There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as SONET/SDH TDM and ATM. This document defines an architecture and framework for a GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions.Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-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-gmpls-ethernet-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27054310.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Oct 27 11:13:45 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 524503A6B33 for ; Mon, 27 Oct 2008 11:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 So8b11NwigJQ for ; Mon, 27 Oct 2008 11:13:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 813DD3A6AD0 for ; Mon, 27 Oct 2008 11:13:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuWSc-0001NN-4c for ccamp-data@psg.com; Mon, 27 Oct 2008 18:05:02 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuWSW-0001MO-9r for ccamp@ops.ietf.org; Mon, 27 Oct 2008 18:04:59 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id m9RI4q8l021285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Oct 2008 11:04:54 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <490602C4.5000403@grotto-networking.com> Date: Mon, 27 Oct 2008 11:04:52 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: CCAMP times in Minneapolis... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi working group chairs, from the IETF meeting agenda it looks like there are three meeting times for CCAMP: Monday: 1740-1930 Afternoon Session III Wednesday: 0900-1015 Morning Session I Wednesday: 1030-1130 Morning Session II Are these fairly solid? Not that I don't like Minneapolis... Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From owner-ccamp@ops.ietf.org Mon Oct 27 22:21:45 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 AEF4E3A68E7 for ; Mon, 27 Oct 2008 22:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.276, 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 fXmbykYOtsFM for ; Mon, 27 Oct 2008 22:21:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCF223A68B9 for ; Mon, 27 Oct 2008 22:21:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KugvA-0008hT-Os for ccamp-data@psg.com; Tue, 28 Oct 2008 05:15:12 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kugv0-0008f3-Ay for ccamp@ops.ietf.org; Tue, 28 Oct 2008 05:15:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 84EDF3A68E7; Mon, 27 Oct 2008 22: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-mpls-graceful-shutdown-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081028051501.84EDF3A68E7@core3.amsl.com> Date: Mon, 27 Oct 2008 22:15:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Category: Informational Expires: April 27, 2009 October 28, 2008 Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-07.txt Pages : 11 Date : 2008-10-27 MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-07.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-mpls-graceful-shutdown-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27220717.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Tue Oct 28 03:22: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 96F473A691C for ; Tue, 28 Oct 2008 03:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 Ug4x5yOWnjb8 for ; Tue, 28 Oct 2008 03:22:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF2453A682A for ; Tue, 28 Oct 2008 03:22:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KulYr-0008HO-EB for ccamp-data@psg.com; Tue, 28 Oct 2008 10:12:29 +0000 Received: from [192.71.80.124] (helo=neo.viciousnest.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KulYk-0008Gp-Td for ccamp@ops.ietf.org; Tue, 28 Oct 2008 10:12:26 +0000 Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id F15B33D2E; Tue, 28 Oct 2008 11:12:20 +0100 (CET) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06060-09; Tue, 28 Oct 2008 11:12:19 +0100 (CET) Received: from [192.36.157.201] (dhcp201.verkstad.net [192.36.157.201]) by neo.viciousnest.net (Postfix) with ESMTP id DC5B93D28; Tue, 28 Oct 2008 11:12:19 +0100 (CET) Message-ID: <4906E57E.4050105@pi.nu> Date: Tue, 28 Oct 2008 11:12:14 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3 , "ahtmpls@itu.int" , ccamp Subject: draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at viciousnest.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Working group(s), this is to initiate a two week poll to see if draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a mpls working group document. The current draft is a merge of to earlier draft one that defined the GAL and another that specified the generic associated channel. Please send your responses to the mpls working group mailing list (needs a bit of discipline, "replay all" won't do the trick ;) . Please respond on Tuesday Oct 11 the latest. /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 Tue Oct 28 06:46:55 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 6ED8528C2A2 for ; Tue, 28 Oct 2008 06:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-1.081, 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 lnhFBAWjY+re for ; Tue, 28 Oct 2008 06:46:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 876A028C29F for ; Tue, 28 Oct 2008 06:46:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuonG-0000Nn-Gn for ccamp-data@psg.com; Tue, 28 Oct 2008 13:39:34 +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 1Kuomv-0000Lh-45 for ccamp@ops.ietf.org; Tue, 28 Oct 2008 13:39:29 +0000 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9SDccUO014833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 14:38:38 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9SDcaJq005134; Tue, 28 Oct 2008 14:38:38 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 14:38:36 +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] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Tue, 28 Oct 2008 14:38:30 +0100 Message-ID: <43284B5A95E36B4AB4A91EBA4E0FC31EE6B78B@DEMUEXC030.nsn-intra.net> In-Reply-To: <4906E57E.4050105@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Thread-Index: Ack45a9i7kRm6Nr9R/u0ZP5cd7068QAHK5Iw References: <4906E57E.4050105@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , "pwe3" , , "ccamp" X-OriginalArrivalTime: 28 Oct 2008 13:38:36.0332 (UTC) FILETIME=[7A6AFEC0:01C93902] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081028143838-115F1BB0-41EA3429/0-0/0-15 X-purgate-size: 1216/0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: I support. Nurit -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Tuesday, October 28, 2008 12:12 To: mpls@ietf.org; pwe3; ahtmpls@itu.int; ccamp Subject: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Working group(s), this is to initiate a two week poll to see if draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a mpls working group document. The current draft is a merge of to earlier draft one that defined the GAL and another that specified the generic associated channel. Please send your responses to the mpls working group mailing list (needs a bit of discipline, "replay all" won't do the trick ;) . Please respond on Tuesday Oct 11 the latest. /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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From owner-ccamp@ops.ietf.org Tue Oct 28 09:50: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 DBCA328C2DD for ; Tue, 28 Oct 2008 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 0wX4hXreGafk for ; Tue, 28 Oct 2008 09:50:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BCD728C30A for ; Tue, 28 Oct 2008 09:50:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KurfG-000LJL-60 for ccamp-data@psg.com; Tue, 28 Oct 2008 16:43:30 +0000 Received: from [143.209.238.162] (helo=audl953.usa.alcatel.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kurf6-000LIP-M4 for ccamp@ops.ietf.org; Tue, 28 Oct 2008 16:43:25 +0000 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id m9SGh3hL021647; Tue, 28 Oct 2008 10:43:03 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 28 Oct 2008 11:43:03 -0500 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: [mpls] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Tue, 28 Oct 2008 11:43:01 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04C95204@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <4906E57E.4050105@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Thread-Index: Ack45byfagYrwvvLT9mCMeJee3MqKwANnugw References: <4906E57E.4050105@pi.nu> From: "AISSAOUI Mustapha" To: "Loa Andersson" , , "pwe3" , , "ccamp" X-OriginalArrivalTime: 28 Oct 2008 16:43:03.0411 (UTC) FILETIME=[3EE93C30:01C9391C] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: support. Mustapha.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Tuesday, October 28, 2008 6:12 AM > To: mpls@ietf.org; pwe3; ahtmpls@itu.int; ccamp > Subject: [mpls] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc >=20 > Working group(s), >=20 > this is to initiate a two week poll to see if=20 > draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a=20 > mpls working group document. >=20 > The current draft is a merge of to earlier draft one that=20 > defined the GAL and another that specified the generic=20 > associated channel. >=20 > Please send your responses to the mpls working group mailing=20 > list (needs a bit of discipline, "replay all" > won't do the trick ;) . >=20 > Please respond on Tuesday Oct 11 the latest. >=20 > /Loa >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From owner-ccamp@ops.ietf.org Tue Oct 28 11:40: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 BC6E928C2FF for ; Tue, 28 Oct 2008 11:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 u-m0xmOCp68r for ; Tue, 28 Oct 2008 11:40:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA43128C2FE for ; Tue, 28 Oct 2008 11:40:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KutPZ-0006Ac-GX for ccamp-data@psg.com; Tue, 28 Oct 2008 18:35:25 +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 1KutP8-00065G-9a for ccamp@ops.ietf.org; Tue, 28 Oct 2008 18:35:04 +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 m9SIXWW1015400; Tue, 28 Oct 2008 18:33:32 GMT 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 m9SIXViZ015394; Tue, 28 Oct 2008 18:33:31 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Loa Andersson" , "ccamp" Cc: , "pwe3" , References: <4906E57E.4050105@pi.nu> Subject: Re: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Tue, 28 Oct 2008 18:33:28 -0000 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support ----- Original Message ----- From: "Loa Andersson" To: ; "pwe3" ; ; "ccamp" Sent: Tuesday, October 28, 2008 10:12 AM Subject: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc > Working group(s), > > this is to initiate a two week poll to see if > draft-bocci-mpls-tp-gach-gal-00.txt is in shape to > become a mpls working group document. > > The current draft is a merge of to earlier draft > one that defined the GAL and another that specified > the generic associated channel. > > Please send your responses to the mpls working group > mailing list (needs a bit of discipline, "replay all" > won't do the trick ;) . > > Please respond on Tuesday Oct 11 the latest. > > /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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From owner-ccamp@ops.ietf.org Tue Oct 28 13:35: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 474273A6C00 for ; Tue, 28 Oct 2008 13:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=-0.876, 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 CQhB3R1svv0P for ; Tue, 28 Oct 2008 13:35:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C4A528C296 for ; Tue, 28 Oct 2008 13:35:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuvBP-000Gen-PT for ccamp-data@psg.com; Tue, 28 Oct 2008 20:28:55 +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 1KuvBH-000GdW-Nd for ccamp@ops.ietf.org; Tue, 28 Oct 2008 20:28:52 +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 m9SKSYT0016321; Tue, 28 Oct 2008 20:28:36 GMT 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 m9SKSXPc016315; Tue, 28 Oct 2008 20:28:33 GMT Message-ID: <2190D314F17643408E235459D4268B44@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Greg Bernstein" , References: <490602C4.5000403@grotto-networking.com> Subject: Re: CCAMP times in Minneapolis... Date: Tue, 28 Oct 2008 20:28:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Greg, As far as we know these sessions are secure. The "two" sessions on Wednesday morning equate to a usual 2.5 hour session. We would not propose to break for 15 minutes in the middle. Adrian ----- Original Message ----- From: "Greg Bernstein" To: Sent: Monday, October 27, 2008 6:04 PM Subject: CCAMP times in Minneapolis... > Hi working group chairs, from the IETF meeting agenda it looks like there > are three meeting times for CCAMP: > Monday: 1740-1930 Afternoon Session III > Wednesday: 0900-1015 Morning Session I > Wednesday: 1030-1130 Morning Session II > > Are these fairly solid? Not that I don't like Minneapolis... > > Regards > > Greg > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > From owner-ccamp@ops.ietf.org Tue Oct 28 17:04:02 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 857973A6953 for ; Tue, 28 Oct 2008 17:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 QwenBExlBMRB for ; Tue, 28 Oct 2008 17:04:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B10973A681A for ; Tue, 28 Oct 2008 17:04:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuySH-0007bt-Ih for ccamp-data@psg.com; Tue, 28 Oct 2008 23:58:33 +0000 Received: from [135.245.0.35] (helo=ihemail2.lucent.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuySB-0007bY-Cj for ccamp@ops.ietf.org; Tue, 28 Oct 2008 23:58:30 +0000 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m9SNvYaH029290; Tue, 28 Oct 2008 18:57:35 -0500 (CDT) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 18:57:34 -0500 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 05:27:28 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Wed, 29 Oct 2008 05:27:51 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965020E933C@INEXC1U01.in.lucent.com> In-Reply-To: <4906E57E.4050105@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Thread-Index: Ack45bUGrlNTVozhT3OOzOfxULkNngAc0CAQ References: <4906E57E.4050105@pi.nu> From: "Dutta, Pranjal K \(Pranjal\)" To: "Loa Andersson" , , "pwe3" , , "ccamp" X-OriginalArrivalTime: 28 Oct 2008 23:57:28.0609 (UTC) FILETIME=[EEFAD110:01C93958] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support. Thanks, Pranjal=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, October 28, 2008 3:12 AM To: mpls@ietf.org; pwe3; ahtmpls@itu.int; ccamp Subject: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Working group(s), this is to initiate a two week poll to see if draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a mpls working group document. The current draft is a merge of to earlier draft one that defined the GAL and another that specified the generic associated channel. Please send your responses to the mpls working group mailing list (needs a bit of discipline, "replay all" won't do the trick ;) . Please respond on Tuesday Oct 11 the latest. /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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From owner-ccamp@ops.ietf.org Wed Oct 29 07:54: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 A2E4828C3AF for ; Wed, 29 Oct 2008 07:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.245, 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 5OtLeG-HY9Uc for ; Wed, 29 Oct 2008 07:54:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7966128C38E for ; Wed, 29 Oct 2008 07:54:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvCIL-000Nta-7l for ccamp-data@psg.com; Wed, 29 Oct 2008 14:45:13 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvCIA-000Ns7-8E for ccamp@ops.ietf.org; Wed, 29 Oct 2008 14:45:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 5B3E43A6D27; Wed, 29 Oct 2008 07: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-mpls-graceful-shutdown-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081029144501.5B3E43A6D27@core3.amsl.com> Date: Wed, 29 Oct 2008 07:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-08.txt Pages : 11 Date : 2008-10-29 MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. Ali et al. Expires April 2009 [page 1] draft-ietf-ccamp-mpls-graceful-shutdown-08.txt A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-08.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-mpls-graceful-shutdown-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-29073434.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Wed Oct 29 08:07: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 501C228C3AF for ; Wed, 29 Oct 2008 08:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.054 X-Spam-Level: X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[AWL=-2.051, 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 iEKy+N1idEcY for ; Wed, 29 Oct 2008 08:07:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBCDC3A6D1F for ; Wed, 29 Oct 2008 08:07:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvCXJ-000PXK-G7 for ccamp-data@psg.com; Wed, 29 Oct 2008 15:00:41 +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 1KvCWy-000PUw-KA for ccamp@ops.ietf.org; Wed, 29 Oct 2008 15:00: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 m9TF0Hto026631 for ; Wed, 29 Oct 2008 15:00:17 GMT 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 m9TF0Gsb026611 for ; Wed, 29 Oct 2008 15:00:16 GMT Message-ID: <6C772407ED48420A961F4FC314886249@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Status of draft-ietf-ccamp-gmpls-g-694-lambda-labels ? Date: Wed, 29 Oct 2008 15:00:03 -0000 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, I know that there was some discussion about changes needed to this I-D, but everything seems to have gone quiet. The last comments on the mailing list are dated just after the current version was published, and I think that there were a few small points raised in Dublin. I think we should try to close off this piece of work as soon as possible. Could the authors and editor make a desperate scramble to get a new version out in time for Minneapolis so that we can declare success and move on? Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Oct 29 08:42: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 E297F3A6AAF for ; Wed, 29 Oct 2008 08:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=-2.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] 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 bggEdxyRhoum for ; Wed, 29 Oct 2008 08:42:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FDBC3A6A36 for ; Wed, 29 Oct 2008 08:42:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvD70-0003dw-HU for ccamp-data@psg.com; Wed, 29 Oct 2008 15:37:34 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvD6j-0003bk-AY for ccamp@ops.ietf.org; Wed, 29 Oct 2008 15:37:23 +0000 X-IronPort-AV: E=Sophos;i="4.33,506,1220227200"; d="scan'208,217";a="26061399" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2008 15:37:16 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9TFbG92005703; Wed, 29 Oct 2008 11:37:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9TFbGeO007347; Wed, 29 Oct 2008 15:37:16 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 11:37:15 -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_01C939DC.20E4766F" Subject: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Wed, 29 Oct 2008 11:36:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53B6q/yDjWG9SR6aYcY8pbCH7Cw== From: "Zafar Ali (zali)" To: "Lou Berger" Cc: "Adrian Farrel" , , , , "Anca Zamfir (ancaz)" , "Newton, Jonathan" X-OriginalArrivalTime: 29 Oct 2008 15:37:15.0817 (UTC) FILETIME=[385FF190:01C939DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2153; t=1225294636; x=1226158636; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20Updates=20to=20draft-ietf-ccamp-mpls-graceful-s hutdown |Sender:=20 |To:=20=22Lou=20Berger=22=20; bh=VpMzwXBbUpvFyawbxtsGUvOe0/blVvr7ge7PGZr/nWQ=; b=dvkSajH3hEhGr/aHup9lqzBqSMfBNk5kASXkTXERoKZR0xhyeJqMKqIUl8 XWODIm2mQ8ltAZnQiw9P7WrkLJhKrhVhJ2C+JuLHCDz1Em/lz+qzqeNYn6bR YKyS5GUwpr; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C939DC.20E4766F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou, Adrian, Deborah, et al-=20 We have modified the draft-ietf-ccamp-mpls-graceful-shutdown to reflect changes proposed in "draft-ietf-mpls-gmpls-lsp-reroute". This was a comment from Lou during the last call of this draft. This was the only outstanding comment from the LC.=20 In the light of the above, can you please take a quick look at draft-ietf-ccamp-mpls-graceful-shutdown-08.txt to make sure that the changes are correctly in synch with the draft-ietf-mpls-gmpls-lsp-reroute work.=20 Thanks for your input.=20 Regards... Zafar=20 ------_=_NextPart_001_01C939DC.20E4766F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updates to draft-ietf-ccamp-mpls-graceful-shutdown

Hi Lou, Adrian, = Deborah, et al-

We have modified the = draft-ietf-ccamp-mpls-graceful-shutdown to reflect changes proposed in = "draft-ietf-mpls-gmpls-lsp-reroute". This was a comment from = Lou during the last call of this draft. This was the only outstanding = comment from the LC.

In the light of the = above, can you please take a quick look at = draft-ietf-ccamp-mpls-graceful-shutdown-08.txt to make sure that the = changes are correctly in synch with the = draft-ietf-mpls-gmpls-lsp-reroute work.

Thanks for your = input.

Regards... = Zafar=20

------_=_NextPart_001_01C939DC.20E4766F-- From owner-ccamp@ops.ietf.org Wed Oct 29 09:06: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 0F0B83A6D3D for ; Wed, 29 Oct 2008 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, 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 BeNMEXBc3kJ0 for ; Wed, 29 Oct 2008 09:06:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4949A3A6A17 for ; Wed, 29 Oct 2008 09:06:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvDPO-0005hs-RG for ccamp-data@psg.com; Wed, 29 Oct 2008 15:56:34 +0000 Received: from [69.89.18.151] (helo=outbound-mail-31.bluehost.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvDPE-0005gW-Iv for ccamp@ops.ietf.org; Wed, 29 Oct 2008 15:56:28 +0000 Received: (qmail 24231 invoked by uid 0); 29 Oct 2008 15:56:21 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy2.bluehost.com with SMTP; 29 Oct 2008 15:56:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=YeYob4qHtee2ukmqdDvuS76a7fonCCUnlPfU3SxKfd9FkSt7k7EyZU54KS//AV7wgB+DVEkS6mvzKbn8qmxhBMoBcvjc8d/BuqwQ+ILJqSlcNpUpoHbmzpDGnEY6R1vR; Received: from box474.bluehost.com ([74.220.219.74] helo=LC2.labn.net) by box474.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1KvDPA-0007x4-Ie; Wed, 29 Oct 2008 09:56:20 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Oct 2008 11:56:18 -0400 To: "Zafar Ali (zali)" From: Lou Berger Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Cc: "Lou Berger" ,"Adrian Farrel" , ,,, "Anca Zamfir (ancaz)" , "Newton, Jonathan" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Identified-User: {2629:box474.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.220.219.74 authed with lberger@labn.net} Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: Zafar, Why does the document define new error codes (and why 4)? Is it that the reroute document isn't sufficient clear on how to indicated each of the 4? Is it some other reason? Thanks, Lou At 11:36 AM 10/29/2008, Zafar Ali (zali) wrote: >Hi Lou, Adrian, Deborah, et al- > >We have modified the draft-ietf-ccamp-mpls-graceful-shutdown to >reflect changes proposed in "draft-ietf-mpls-gmpls-lsp-reroute". >This was a comment from Lou during the last call of this draft. This >was the only outstanding comment from the LC. > >In the light of the above, can you please take a quick look at >draft-ietf-ccamp-mpls-graceful-shutdown-08.txt to make sure that the >changes are correctly in synch with the >draft-ietf-mpls-gmpls-lsp-reroute work. > >Thanks for your input. > >Regards... Zafar From owner-ccamp@ops.ietf.org Wed Oct 29 09:39: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 5E3FD3A69EE for ; Wed, 29 Oct 2008 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.409 X-Spam-Level: X-Spam-Status: No, score=-5.409 tagged_above=-999 required=5 tests=[AWL=-1.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, 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 9-bO7YVEtAJQ for ; Wed, 29 Oct 2008 09:39:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EA3F3A69F0 for ; Wed, 29 Oct 2008 09:39:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvE0z-000ALf-TJ for ccamp-data@psg.com; Wed, 29 Oct 2008 16:35:25 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvE0h-000AJO-N6 for ccamp@ops.ietf.org; Wed, 29 Oct 2008 16:35:14 +0000 X-IronPort-AV: E=Sophos;i="4.33,507,1220227200"; d="scan'208";a="111668681" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2008 16:35:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9TGZ6HG029604; Wed, 29 Oct 2008 09:35:06 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9TGZ6Zu011298; Wed, 29 Oct 2008 16:35:06 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 12:35:06 -0400 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: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Wed, 29 Oct 2008 12:34:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbA References: From: "Zafar Ali (zali)" To: "Lou Berger" Cc: "Adrian Farrel" , , , , "Anca Zamfir (ancaz)" , "Newton, Jonathan" X-OriginalArrivalTime: 29 Oct 2008 16:35:06.0082 (UTC) FILETIME=[4CD05C20:01C939E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=972; t=1225298107; x=1226162107; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20RE=3A=20Updates=20to=20draft-ietf-ccamp-mpls-gr aceful-shutdown |Sender:=20; bh=ppTpGEZ3QoX1+7NM1oqTa40cus0UgYf/sATwnuIRL5c=; b=eSCCiP3gLox9mwtGwVq3q7b21frK0PoMP74yvWFfF1vuo1HQFUuuyRyLH9 77zRvpTiaR8ysLoArfFqPuQ0YutWtMo9FNrFN1Pry8OGjmyw/yLFLsgGJD1x RkwyMVU/sC; Authentication-Results: sj-dkim-3; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Lou- =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, October 29, 2008 11:56 AM > To: Zafar Ali (zali) > Cc: Lou Berger; Adrian Farrel; ccamp@ops.ietf.org;=20 > mpls@ietf.org; jpv@cisco.com; Anca Zamfir (ancaz); Newton, Jonathan > Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown >=20 > Zafar, >=20 > Why does the document define new error codes (and why 4)? Is=20 > it that the reroute document isn't sufficient clear on how to=20 > indicated each of the 4? Is it some other reason? >=20 This is because headend may be able to compute alternate route ("reroute" action) for mb4b differently, depending on the resource under graceful shutdown, as detailed in the document. Hence one code is define for TE node, TE link, component link of a bundled TE link, and label resource, each.=20 Thanks Regards... Zafar=20 From owner-ccamp@ops.ietf.org Wed Oct 29 10:35: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 9246B3A6A37 for ; Wed, 29 Oct 2008 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=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 3eFBIIXgaQhh for ; Wed, 29 Oct 2008 10:35:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 777683A6D25 for ; Wed, 29 Oct 2008 10:35:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvEsF-000FSo-Pg for ccamp-data@psg.com; Wed, 29 Oct 2008 17:30:27 +0000 Received: from [67.222.38.38] (helo=outbound-mail-148.bluehost.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvEs7-000FSD-Jg for ccamp@ops.ietf.org; Wed, 29 Oct 2008 17:30:23 +0000 Received: (qmail 11878 invoked by uid 0); 29 Oct 2008 17:30:17 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy5.bluehost.com with SMTP; 29 Oct 2008 17:30:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=bQv7GusXQAl1Eaj2ykrwVGf0zWTuxzGkB3B9LZDN1R9GLafSyLpDfLGdXv+nqxxpl17sTi52e0SnmQC9T28ULEC9S+woTmHWjHqZla9eHjPP6JMMXe/WVQsd1yabfxAr; Received: from box474.bluehost.com ([74.220.219.74] helo=LC2.labn.net) by box474.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1KvErm-0000zU-NL; Wed, 29 Oct 2008 11:29:58 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Oct 2008 13:29:49 -0400 To: "Zafar Ali (zali)" From: Lou Berger Subject: RE: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Cc: "Lou Berger" ,"Adrian Farrel" , ,,, "Anca Zamfir (ancaz)" , "Newton, Jonathan" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Identified-User: {2629:box474.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.220.219.74 authed with lberger@labn.net} Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: Zafar, In short, you don't need new error codes to support the upstream identification of type of reroute being indicated (node, interface, component, label). This can be determined based on the ERROR_SPEC object and included TLVs. This is already covered in the reroute draft. I thought the text at the end of 2.1 of the reroute draft was sufficiently clear to indicate how one would do this with the existing error codes. I guess some examples for each of the cases will make this more apparent. looks like there are still open issues in the draft(s)... Lou At 12:34 PM 10/29/2008, Zafar Ali (zali) wrote: >Hi Lou- > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > Sent: Wednesday, October 29, 2008 11:56 AM > > To: Zafar Ali (zali) > > Cc: Lou Berger; Adrian Farrel; ccamp@ops.ietf.org; > > mpls@ietf.org; jpv@cisco.com; Anca Zamfir (ancaz); Newton, Jonathan > > Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown > > > > Zafar, > > > > Why does the document define new error codes (and why 4)? Is > > it that the reroute document isn't sufficient clear on how to > > indicated each of the 4? Is it some other reason? > > > >This is because headend may be able to compute alternate route >("reroute" action) for mb4b differently, depending on the resource under >graceful shutdown, as detailed in the document. Hence one code is define >for TE node, TE link, component link of a bundled TE link, and label >resource, each. > >Thanks > >Regards... Zafar > > From owner-ccamp@ops.ietf.org Wed Oct 29 12:54: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 1F0463A6ABB for ; Wed, 29 Oct 2008 12:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.557, 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 m+EglKvB6XvN for ; Wed, 29 Oct 2008 12:54:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 565C53A6AB5 for ; Wed, 29 Oct 2008 12:54:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvH1T-000PmS-Ku for ccamp-data@psg.com; Wed, 29 Oct 2008 19:48:07 +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 1KvH1M-000Plr-7u for ccamp@ops.ietf.org; Wed, 29 Oct 2008 19:48:03 +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 m9TJlufp023189 for ; Wed, 29 Oct 2008 19:47:56 GMT 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 m9TJlt9U023183 for ; Wed, 29 Oct 2008 19:47:56 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Wed, 29 Oct 2008 19:47:49 -0000 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This email starts a two week working group last call on "GMPLS Ethernet Label Switching Architecture and Framework" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-03.txt The I-D is marked as Informational. Please send your comments to the list by 12 noon GMT Friday 14th November. Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Wed Oct 29 13:04: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 A82C93A69A3 for ; Wed, 29 Oct 2008 13:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.245, 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 MIDnsp8QIEPr for ; Wed, 29 Oct 2008 13:04:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C18803A68F4 for ; Wed, 29 Oct 2008 13:04:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvHDC-0000ja-1h for ccamp-data@psg.com; Wed, 29 Oct 2008 20:00:14 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvHD3-0000j6-5C for ccamp@ops.ietf.org; Wed, 29 Oct 2008 20:00:09 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id BD7213A685A; Wed, 29 Oct 2008 13:00:04 -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-ason-routing-ospf-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081029200004.BD7213A685A@core3.amsl.com> Date: Wed, 29 Oct 2008 13:00:04 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : OSPFv2 Routing Protocols Extensions for ASON Routing Author(s) : D. Papadimitriou, I. Property Filename : draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt Pages : 27 Date : 2008-10-29 The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines to the OSPFv2 Link State Routing Protocol to meet the routing requirements for routing in an ASON. D.Papadimitriou et al. - Expires April 2009 [page 1] draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt October 2008 Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-06.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-ason-routing-ospf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-29124635.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Wed Oct 29 13:42:03 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 B79723A6B28 for ; Wed, 29 Oct 2008 13:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.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, 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 TKn8v6LkUDtT for ; Wed, 29 Oct 2008 13:42:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4B883A6AF3 for ; Wed, 29 Oct 2008 13:42:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvHjH-0003rO-Lq for ccamp-data@psg.com; Wed, 29 Oct 2008 20:33:23 +0000 Received: from [198.4.8.166] (helo=ashesmtp02.verizonbusiness.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvHj4-0003pz-Re for ccamp@ops.ietf.org; Wed, 29 Oct 2008 20:33:18 +0000 Received: from pmismtp02.mcilink.com ([166.37.158.162]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9I00B18P1WWQ00@firewall.verizonbusiness.com> for ccamp@ops.ietf.org; Wed, 29 Oct 2008 20:32:21 +0000 (GMT) Received: from pmismtp02.mcilink.com ([127.0.0.1]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0K9I00326P1WBM@pmismtp02.mcilink.com> for ccamp@ops.ietf.org; Wed, 29 Oct 2008 20:32:20 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0K9I001FBP1W8Z@pmismtp02.mcilink.com> for ccamp@ops.ietf.org; Wed, 29 Oct 2008 20:32:20 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.135]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 20:32:19 +0000 Date: Wed, 29 Oct 2008 20:32:19 +0000 From: "So, Ning" Subject: New draft of the framework and requirements for Composite Transport Group To: ccamp@ops.ietf.org Message-id: <84042721A487BB4C83FC772185400CB707C7498B@ASHEVS010.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C93A05.7084F1DB" Content-class: urn:content-classes:message Thread-topic: New draft of the framework and requirements for Composite Transport Group Thread-index: Ack6BXCmfOqsCudJSfyuUtnJ5SiqIw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Oct 2008 20:32:19.0712 (UTC) FILETIME=[70B7F000:01C93A05] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93A05.7084F1DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 We have uploaded the draft of the framework and requirements for Composite Transport Group. =20 http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-framework-req uirement-00.txt =20 Abstract =20 This document states a traffic distribution problem in today's IP/ =20 MPLS network when multiple links are configured between two routers. =20 The document presents a Composite Transport Group framework as the =20 solution for the problems and specifies a set of requirements for =20 Composite Transport Group(CTG). =20 We appreciate your input/comments and look forward to discussing in Minneapolis. =20 =20 Ning So Lead Engineer Data Traffic Engineering 972-729-7905 =20 =20 ------_=_NextPart_001_01C93A05.7084F1DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

We have uploaded = the draft of the framework and requirements for Composite Transport = Group.

 

http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-frame= work-requirement-00.txt

 

Abstract

 

   This = document states a traffic distribution problem in today's IP/

 

   MPLS = network when multiple links are configured between two = routers.

 

   The = document presents a Composite Transport Group framework as the

 

   = solution for the problems and specifies a set of requirements for

 

   = Composite Transport Group(CTG).

 

We appreciate your input/comments and look forward to discussing in Minneapolis.<= /p>

 

 

Ning So

Lead Engineer

Data Traffic Engineering

972-729-7905

 

 

------_=_NextPart_001_01C93A05.7084F1DB-- From owner-ccamp@ops.ietf.org Wed Oct 29 13:53: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 96E163A6B19 for ; Wed, 29 Oct 2008 13:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.969 X-Spam-Level: * X-Spam-Status: No, score=1.969 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067, 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 8IrWRXSsSUS5 for ; Wed, 29 Oct 2008 13:52:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A2D0C3A6B4C for ; Wed, 29 Oct 2008 13:52:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvHx5-00056i-SW for ccamp-data@psg.com; Wed, 29 Oct 2008 20:47:39 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvHwm-000550-7I for ccamp@ops.ietf.org; Wed, 29 Oct 2008 20:47:33 +0000 Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 20:47:15 +0000 Received: from 217.32.164.172 ([217.32.164.172]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.26]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Oct 2008 20:47:15 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 29 Oct 2008 16:47:14 -0400 Subject: Re: New draft of the framework and requirements for Composite Transport Group From: "Thomas D. Nadeau" To: "So, Ning" , , "Andrew G. (Andy) Malis" Message-ID: Thread-Topic: New draft of the framework and requirements for Composite Transport Group Thread-Index: Ack6BXCmfOqsCudJSfyuUtnJ5SiqIwAAhUZf In-Reply-To: <84042721A487BB4C83FC772185400CB707C7498B@ASHEVS010.mcilink.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3308143634_2905413" X-OriginalArrivalTime: 29 Oct 2008 20:47:15.0770 (UTC) FILETIME=[86CF89A0:01C93A07] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3308143634_2905413 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Have you guys given any thought to the OAM ramifications of your approach? I see no discussion of this in the draft. I ask because extensions were done to LSP ping which took great pains to make work correctly. Have you thought about how to trouble-shoot this mechanism if there are faults? --Tom On 10/29/08 4:32 PM, "So, Ning" wrote: > Dear all, > > We have uploaded the draft of the framework and requirements for Composite > Transport Group. > > http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-framework-requireme > nt-00.txt > > Abstract > > This document states a traffic distribution problem in today's IP/ > > MPLS network when multiple links are configured between two routers. > > The document presents a Composite Transport Group framework as the > > solution for the problems and specifies a set of requirements for > > Composite Transport Group(CTG). > > We appreciate your input/comments and look forward to discussing in > Minneapolis. > > > Ning So > Lead Engineer > Data Traffic Engineering > 972-729-7905 > > > --B_3308143634_2905413 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: New draft of the framework and requirements for Composite Transp= ort Group
    Have you guys given any thought to the OAM ramifica= tions of your approach? I see no discussion of this in the draft.  I as= k because extensions were done to LSP ping which took  great pains to m= ake work correctly.  Have you thought about how to trouble-shoot this m= echanism if there are faults?

    --Tom



On 10/29/08 4:32 PM, "So, Ning" <ning.so@verizonbusiness.com> wrote:

Dear all,
 
We have uploaded the draft of the framework and requirements for Composite = Transport Group.
 
http://www.ietf.org/internet-drafts/draft-so-yong-mpl= s-ctg-framework-requirement-00.txt
 
Abstract
 
   This document states a traffic distribution problem in to= day's IP/
 
   MPLS network when multiple links are configured between t= wo routers.
 
   The document presents a Composite Transport Group framewo= rk as the
 
   solution for the problems and specifies a set of requirem= ents for
 
   Composite Transport Group(CTG).
 
We appreciate your input/comments and look forward to discussing in Minneap= olis.
 
Ning So
Lead Engineer
Data Traffic Engineering
972-729-7905
 

--B_3308143634_2905413-- From owner-ccamp@ops.ietf.org Wed Oct 29 15:01:40 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 6C5F528C3F7 for ; Wed, 29 Oct 2008 15:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 mjU-xtvPFb9M for ; Wed, 29 Oct 2008 15:01:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26A5C28C3EF for ; Wed, 29 Oct 2008 15:00:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvIwv-000AfE-M3 for ccamp-data@psg.com; Wed, 29 Oct 2008 21:51:33 +0000 Received: from [199.249.25.195] (helo=omzesmtp01a.verizonbusiness.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvIwo-000AeN-5F for ccamp@ops.ietf.org; Wed, 29 Oct 2008 21:51:29 +0000 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0K9I00D6XSPOO000@firewall.verizonbusiness.com> for ccamp@ops.ietf.org; Wed, 29 Oct 2008 21:51:24 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0K9I00FOHSPNKN@dgismtp01.mcilink.com> for ccamp@ops.ietf.org; Wed, 29 Oct 2008 21:51:24 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([153.39.68.165]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0K9I00F75SPNKM@dgismtp01.mcilink.com> for ccamp@ops.ietf.org; Wed, 29 Oct 2008 21:51:23 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.135]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 21:51:23 +0000 Date: Wed, 29 Oct 2008 21:51:22 +0000 From: "So, Ning" Subject: RE: New draft of the framework and requirements for Composite Transport Group In-reply-to: <84042721A487BB4C83FC772185400CB707C7498E@ASHEVS010.mcilink.com> To: ccamp@ops.ietf.org Message-id: <84042721A487BB4C83FC772185400CB707C7498F@ASHEVS010.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C93A10.7BD479A9" Content-class: urn:content-classes:message Thread-topic: New draft of the framework and requirements for Composite Transport Group Thread-index: Ack6BXCmfOqsCudJSfyuUtnJ5SiqIwAAhUZfAAHBfvAAAHk+MA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <84042721A487BB4C83FC772185400CB707C7498E@ASHEVS010.mcilink.com> X-OriginalArrivalTime: 29 Oct 2008 21:51:23.0041 (UTC) FILETIME=[7BF68110:01C93A10] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93A10.7BD479A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, =20 Most of the trouble-shooting mechanisms working today should be able to work across CTG as well. I am sure I have not thought of everything, but I have not seen any problems. Could you please be more specific on the problem and the trouble-shooting method you are thinking here? =20 =20 Ning So Lead Engineer Data Traffic Engineering 972-729-7905 =20 ________________________________ From: Thomas D. Nadeau [mailto:tom.nadeau@bt.com]=20 Sent: Wednesday, October 29, 2008 3:47 PM To: So, Ning; ccamp@ops.ietf.org; Andrew G. (Andy) Malis Subject: Re: New draft of the framework and requirements for Composite Transport Group =20 Have you guys given any thought to the OAM ramifications of your approach? I see no discussion of this in the draft. I ask because extensions were done to LSP ping which took great pains to make work correctly. Have you thought about how to trouble-shoot this mechanism if there are faults? --Tom On 10/29/08 4:32 PM, "So, Ning" wrote: Dear all, =20 We have uploaded the draft of the framework and requirements for Composite Transport Group. =20 http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-framework-req uirement-00.txt =20 Abstract =20 This document states a traffic distribution problem in today's IP/ =20 MPLS network when multiple links are configured between two routers. =20 The document presents a Composite Transport Group framework as the =20 solution for the problems and specifies a set of requirements for =20 Composite Transport Group(CTG). =20 We appreciate your input/comments and look forward to discussing in Minneapolis. =20 Ning So Lead Engineer Data Traffic Engineering 972-729-7905 =20 ------_=_NextPart_001_01C93A10.7BD479A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: New draft of the framework and requirements for Composite = Transport Group

Tom,

 

Most of the trouble-shooting = mechanisms working today should be able to work across CTG as well.  I am sure = I have not thought of everything, but I have not seen any problems.  Could = you please be more specific on the problem and the trouble-shooting method = you are thinking here?    

 

Ning So

Lead Engineer

Data Traffic = Engineering

972-729-7905

 

=

From: = Thomas D. Nadeau [mailto:tom.nadeau@bt.com]
Sent: Wednesday, October = 29, 2008 3:47 PM
To: So, Ning; = ccamp@ops.ietf.org; Andrew G. (Andy) Malis
Subject: Re: New draft of = the framework and requirements for Composite Transport = Group

 


    Have you guys given any thought to the OAM ramifications of your approach? I see no discussion of this in the = draft.  I ask because extensions were done to LSP ping which took =  great pains to make work correctly.  Have you thought about how to = trouble-shoot this mechanism if there are faults?

    --Tom



On 10/29/08 4:32 PM, "So, Ning" <ning.so@verizonbusiness.com> = wrote:

Dear all,
 
We have uploaded the draft of the framework and requirements for = Composite Transport Group.
 
http://www.ietf.org/internet-drafts/draft-so-yong= -mpls-ctg-framework-requirement-00.txt
 
Abstract
 
   This document states a traffic distribution problem in today's IP/
 
   MPLS network when multiple links are configured = between two routers.
 
   The document presents a Composite Transport Group = framework as the
 
   solution for the problems and specifies a set of = requirements for
 
   Composite Transport Group(CTG).
 
We appreciate your input/comments and look forward to discussing in = Minneapolis.

 
Ning So
Lead Engineer
Data Traffic Engineering
972-729-7905

 

------_=_NextPart_001_01C93A10.7BD479A9-- From owner-ccamp@ops.ietf.org Wed Oct 29 21:07: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 1C2093A6B3F for ; Wed, 29 Oct 2008 21:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.252, 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 xztJplxOIZ6I for ; Wed, 29 Oct 2008 21:07:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3700B3A69B3 for ; Wed, 29 Oct 2008 21:07:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvOhe-000Auv-Ad for ccamp-data@psg.com; Thu, 30 Oct 2008 04:00:10 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvOhW-000AuG-8i for ccamp@ops.ietf.org; Thu, 30 Oct 2008 04:00:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id C6DF93A6908; Wed, 29 Oct 2008 21: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-confirm-data-channel-status-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081030040001.C6DF93A6908@core3.amsl.com> Date: Wed, 29 Oct 2008 21:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Data Channel Status Confirmation Extensions for the Link Management Protocol Author(s) : D. Li, et al. Filename : draft-ietf-ccamp-confirm-data-channel-status-01.txt Pages : 15 Date : 2008-10-29 This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-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-confirm-data-channel-status-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-29204657.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 30 08:41: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 4726F3A6992 for ; Thu, 30 Oct 2008 08:41:05 -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 vwuR6fWnAquz for ; Thu, 30 Oct 2008 08:41:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5C013A6951 for ; Thu, 30 Oct 2008 08:41:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvZXl-000Aqw-KK for ccamp-data@psg.com; Thu, 30 Oct 2008 15:34: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 1KvZXV-000Apg-WB for ccamp@ops.ietf.org; Thu, 30 Oct 2008 15:34:31 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id D76283A6A82; Thu, 30 Oct 2008 08:34:25 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Protocol Action: 'ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Proposed Standard Message-Id: <20081030153425.D76283A6A82@core3.amsl.com> Date: Thu, 30 Oct 2008 08:34:25 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: The IESG has approved the following document: - 'ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering ' as a Proposed Standard 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-isis-interas-te-extension-04.txt Technical Summary This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. Working Group Summary Good consensus reported. The document has had a good level of discussions and review in CCAMP and in the ISIS working group. In particular, it received considerable input from IS-IS experts in its early stages. It was last called in both CCAMP and IS-IS working groups and updated in response to comments. Document Quality There is a known implementation of the extensions, in addition to a known implementation of the very similar OSPF document. There was also good support for the work from other vendors with the same objectives. Document review by the IS-IS working group deserves special mention for its care and thoroughness. Personnel Adrian Farrel is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note Please add the following text to the end of the first paragraph of section 5 (security considerations): (e.g., using the cleartext passwords or Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm which are defined in [ISIS] and [RFC3567bis] separately.)" Please add the following paragraph to the end of section 5 (security considerations): For a discussion of general security considerations for IS-IS see [RFC3567bis]. Please add RFC3567bis to section 8.1 (normative references), this refers to draft-ietf-isis-rfc3567bis (which should be an RFC ahead of this draft -- it is now RFC 5304). Please update Section 6.2 as follows: OLD This document defines the following new sub-TLV types, described in Sections 3.3.1, 3.3.2 and 3.3.3, of top-level TLV 141 (see section 6.1 above) that need to be registered in the ISIS sub-TLV registry for TLV 141, note that these three new sub-TLVs SHOULD NOT appear in TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222): Type Description Length ---- ------------------------------ -------- 23 Remote AS number 4 24 IPv4 Remote ASBR Identifier 4 25 IPv6 Remote ASBR Identifier 16 As described above in Section 3.1, the sub-TLVs which are defined in [ISIS-TE], [ISIS-TE-V3] and other documents for describing the TE properties of an TE link are applicable to describe an inter-AS TE link and MAY be included in the Inter-AS Reachability TLV when adverting inter-AS TE links. And it's possible that some sub-TLVs may be defined for inclusion in both TLV 22 and TLV 141 in the future. It's better if these sub-TLVs have the same registry value no matter where they are included in TLV 22 or TLV 141. The same condition will occur when these sub-TLVs need to be included in TLV 222. So, in order to simplify the registration and reduce the potential code point conflict, this document suggests that TLV 22, TLV 141 and TLV 222 share the same sub-TLV registry. The proposal is that change the current Registry Name from "Sub-TLVs for TLV 22" to "Sub-TLVs for TLV 22, 141 and 222" and add three columns ("May be present on TLV 22","May be present on TLV 141" and "May be present on TLV 222") to the registry for indicating whether a specific sub- TLV may be present on the TLV. NEW This document defines the following new sub-TLV types, described in Sections 3.3.1, 3.3.2 and 3.3.3, of top-level TLV 141 (see section 6.1 above) that need to be registered in the ISIS sub-TLV registry for TLV 141, note that these three new sub-TLVs SHOULD NOT appear in TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222): Type Description ---- ------------------------------ 24 Remote AS number 25 IPv4 Remote ASBR Identifier 26 IPv6 Remote ASBR Identifier As described above in Section 3.1, the sub-TLVs which are defined in [ISIS-TE], [ISIS-TE-V3] and other documents for describing the TE properties of an TE link are applicable to describe an inter-AS TE link and MAY be included in the Inter-AS Reachability TLV when adverting inter-AS TE links. IANA is requested to update the registry currently specified as "Sub-TLVs for TLV 22" to be named "Sub-TLVs for TLVs 22, 141, and 222". Three new columns should be added to the registry to show in which TLVs the sub-TLVs may be present. All sub-TLVs currently defined may be present in all three TLVs, hence the registry (with the definition of the new sub-TLVs defined here) should read as follows. TLV TLV TLV Type Description 22 141 222 Reference ------- ------------------------------------ --- --- --- --------- 0 Unassigned y y y 1 Unassigned y y y 2 Unassigned y y y 3 Administrative group (color) y y y [RFC5305] 4 Link Local/Remote Identifiers y y y [RFC4205][RFC5307] 5 Unassigned y y y 6 IPv4 interface address y y y [RFC5305] 7 Unassigned y y y 8 IPv4 neighbor address y y y [RFC5305] 9 Maximum link bandwidth y y y [RFC5305] 10 Maximum reservable link bandwidth y y y [RFC5305] 11 Unreserved bandwidth y y y [RFC5305] 12 Unassigned y y y 13 Unassigned y y y 14 Unassigned y y y 15 Unassigned y y y 16 Unassigned y y y 17 Unassigned y y y 18 TE Default metric y y y [RFC5305] 19 Link-attributes y y y [RFC5029] 20 Link Protection Type y y y [RFC4205][RFC5307] 21 Interface Switching Capability Desc y y y [RFC4205][RFC5307] 22 Bandwidth Constraints y y y [RFC4124] 23 Unconstrained TE LSP Count (sub-)TLV y y y [RFC-ietf-mpls-number-0-bw-te-lsps-12.txt] 24 Remote AS number n y n [This.I-D] 25 IPv4 Remote ASBR Identifier n y n [This.I-D] 26 IPv6 Remote ASBR Identifier n y n [This.I-D] 27-249 Unassigned 250-254 Reserved for Cisco-specific exts 255 Reserved for future expansion Further sub-TLVs may be defined in the future for inclusion in any of the TLVs 22, 141, or 222. The re-naming of the registry as above ensures that there is no accidental overlap of sub-TLV codepoints. The introduction of the columns within the registry clarify the use of the sub-TLVs. IANA Note Please note substantial IANA update in the RFC editor's note. From owner-ccamp@ops.ietf.org Thu Oct 30 12:04: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 DE12B3A6898 for ; Thu, 30 Oct 2008 12:04:09 -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 uasQa8b059Jn for ; Thu, 30 Oct 2008 12:04:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 111E53A6894 for ; Thu, 30 Oct 2008 12:04:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvchG-0004Az-ST for ccamp-data@psg.com; Thu, 30 Oct 2008 18:56: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 1Kvch8-00049F-JP for ccamp@ops.ietf.org; Thu, 30 Oct 2008 18:56:39 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 61BCC3A6909; Thu, 30 Oct 2008 11:56:34 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Protocol Action: 'OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Proposed Standard Message-Id: <20081030185634.61BCC3A6909@core3.amsl.com> Date: Thu, 30 Oct 2008 11:56:34 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: The IESG has approved the following document: - 'OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering ' as a Proposed Standard 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-ospf-interas-te-extension-06.txt Technical Summary This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. Working Group Summary WG has good consensus. The document was also last called in the OSPF working group (as well as CCAMP) and comments resolved. Document Quality There is at least one implementation of the OSPF v2 extensions. No known implementation (yet) of the OSPF v3 extensions (ie, extensions to support IPv6). Document review by Acee Lindem deserves mention for its care and thoroughness. Personnel Adrian Farrel is the document shepherd. Ross Callon is the responsible AD. From owner-ccamp@ops.ietf.org Thu Oct 30 16:47: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 855BE3A6905 for ; Thu, 30 Oct 2008 16:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[AWL=-1.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_EXTNSN=2.3, 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 ok6BbX1FEPLT for ; Thu, 30 Oct 2008 16:47:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 986A73A68CC for ; Thu, 30 Oct 2008 16:47:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvh8J-0005Tk-4t for ccamp-data@psg.com; Thu, 30 Oct 2008 23:40:55 +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 1Kvh8A-0005Ro-BH for ccamp@ops.ietf.org; Thu, 30 Oct 2008 23:40:50 +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 m9UNeaZD008033; Thu, 30 Oct 2008 23:40:38 GMT 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 m9UNeZRt008024; Thu, 30 Oct 2008 23:40:35 GMT Message-ID: <8748264690F046B189E400061FE9FF7D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , References: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: MRN ext. doc Date: Thu, 30 Oct 2008 23:40:27 -0000 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Dimitri, A very quick scan of this I-D raises a few points. === Section 2 references [GR-TELINK]. Is this intended to be draft-ietf-ccamp-mpls-graceful-shutdown-08.txt? There is nothing in the references section to indicate. === Section 8 needs to be resolved === It would make sense for section 7 to reference draft-ietf-mpls-mpls-and-gmpls-security-framework === We will definitely (well, very probably) be asked if we can show traceability back to the requirements. In fact, RFC 5339 includes section 4.1 that gives traceability from the evaluation back to the requirements. Section 2 of this document does not quite give the same level of traceability such that it is necessary to read most of 5339 to ensure that all requirements have been met. === References need updating. idnits should help you. === Section 4 refers to section 8.2 of RFC 4206. Should be 6.2? === Section 4 appears to consider only the mapped server model (allowing a many to one mapping), but not the multiplexed server model. Is it the intention to defer this to Section 5? === Section 5 does not include reference to draft-ietf-ccamp-lsp-hierarchy-bis even though this is mentioned in RFC 5339. Shouldn't it? Actually, there is no mention in section 5 of using RFC 4206 procedures to set up FAs to form virtual TE links although that is clearly intended in 4206. === The Call-Attributes object C-Num is picked from the 11bbbbbb class. Why? Surely if any node that processes the Notify message does not understand the object, you want the Call to fail. === I'm puzzled that the Call described in section 5.1 does not indicate to the intended LSP egress in which layer or region the soon-to-be-set-up LSP will be required to operate. === I don't find section 3.2.1 clear on the co-existence within the Link TLV of the IACD sub-TLV and the ISCD sub-TLV [RFC4203]. === I think it would be valuable to indicate in the Abstract that this work is limited to the application of a single TE domain across multiple regions or layers. Furthermore, in the Introduction where this point is raised, it would be helpful to explain the meaning of a "single TE domain." There is a passable definition in RFC 5212 section 1. It would be worth clarifying whether a single TE domain can be served by more than one IGP instance. This is hinted at in section 5.7 of RFC 5212. === Thanks, Adrian ----- Original Message ----- From: "PAPADIMITRIOU Dimitri" To: Sent: Monday, October 27, 2008 8:04 AM Subject: MRN ext. doc folks - before asking for LC, we plan an update of this doc. see: please let us know if you see any missing description/holes in this version (beside its IANA section). thx, -d. From owner-ccamp@ops.ietf.org Fri Oct 31 01:47: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 E28C33A688C for ; Fri, 31 Oct 2008 01:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.809 X-Spam-Level: ** X-Spam-Status: No, score=2.809 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MANGLED_EXTNSN=2.3, 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 cz1bHktb44Do for ; Fri, 31 Oct 2008 01:47:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E73E28C3FD for ; Fri, 31 Oct 2008 01:46:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvpVQ-000M7n-4q for ccamp-data@psg.com; Fri, 31 Oct 2008 08:37:20 +0000 Received: from [64.208.49.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvpVH-000M78-GD for ccamp@ops.ietf.org; Fri, 31 Oct 2008 08:37:15 +0000 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m9V8b8u1023805; Fri, 31 Oct 2008 09:37:08 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 31 Oct 2008 09:37:07 +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: MRN ext. doc Date: Fri, 31 Oct 2008 09:37:05 +0100 Message-ID: <00275A5B436CA441900CB10936742A38014BA1CA@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <8748264690F046B189E400061FE9FF7D@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MRN ext. doc Thread-Index: Ack66O1Lcar2QjxCSky3c8C+KqTs5QAPqnvQ References: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> <8748264690F046B189E400061FE9FF7D@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 31 Oct 2008 08:37:07.0857 (UTC) FILETIME=[DC160010:01C93B33] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: hi adrian=20 thx for the feedback - here below a couple of hints:=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, October 31, 2008 12:40 AM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: MRN ext. doc >=20 > Hi Dimitri, >=20 > A very quick scan of this I-D raises a few points. >=20 > =3D=3D=3D > Section 2 references [GR-TELINK]. Is this intended to be=20 > draft-ietf-ccamp-mpls-graceful-shutdown-08.txt? > There is nothing in the references section to indicate. yes will add a ref. > =3D=3D=3D > Section 8 needs to be resolved yes already part of the update > =3D=3D=3D > It would make sense for section 7 to reference=20 > draft-ietf-mpls-mpls-and-gmpls-security-framework do you have any specific point not covered by this section and covered by the above ref. > =3D=3D=3D > We will definitely (well, very probably) be asked if we can show=20 > traceability back to the requirements. In fact, RFC 5339=20 > includes section=20 > 4.1 that gives traceability from the evaluation back to the=20 > requirements.=20 > Section 2 of this document does not quite give the same level of=20 > traceability such that it is necessary to read most of 5339=20 > to ensure that=20 > all requirements have been met. the current doc. covers the "delta" in terms of mechanism. so, do you mean that mechanisms not requiring any extensions shall also be included/described in this document ?=20 > =3D=3D=3D > References need updating. idnits should help you. > =3D=3D=3D > Section 4 refers to section 8.2 of RFC 4206. Should be 6.2? yes.=20 > =3D=3D=3D > Section 4 appears to consider only the mapped server model=20 > (allowing a many=20 > to one mapping), but not the multiplexed server model. Is it=20 > the intention=20 > to defer this to Section 5? i don't understand the question.=20 > =3D=3D=3D > Section 5 does not include reference to=20 > draft-ietf-ccamp-lsp-hierarchy-bis=20 > even though this is mentioned in RFC 5339. Shouldn't it? > Actually, there is no mention in section 5 of using RFC 4206=20 > procedures to=20 > set up FAs to form virtual TE links although that is clearly=20 > intended in=20 > 4206. referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206 > =3D=3D=3D > The Call-Attributes object C-Num is picked from the 11bbbbbb=20 > class. Why?=20 > Surely if any node that processes the Notify message does not=20 > understand the=20 > object, you want the Call to fail. this what has been agreed from last meeting. see Lou's preso. > =3D=3D=3D > I'm puzzled that the Call described in section 5.1 does not=20 > indicate to the=20 > intended LSP egress in which layer or region the=20 > soon-to-be-set-up LSP will=20 > be required to operate. because=20 - it is the FA setup that indicates to which bearer the virtual link will be associated not the other way around=20 - the virtual association is used by upper-region LSP so the virtual link itself is an abstraction of the bearer/network (in other terms - and by definition - one does not create Virtual TE links over Virtual TE links) the only condition which can be verified from the TEDB is that both ends of the bearer belongs to the same LSP region (symmetry). > =3D=3D=3D > I don't find section 3.2.1 clear on the co-existence within=20 > the Link TLV of=20 > the IACD sub-TLV and the ISCD sub-TLV [RFC4203]. i will add a statement IACD does not modify format/messaging and processing associated to the ISCD. > =3D=3D=3D > I think it would be valuable to indicate in the Abstract that=20 > this work is=20 > limited to the application of a single TE domain across=20 > multiple regions or=20 > layers. > Furthermore, in the Introduction where this point is raised,=20 > it would be=20 > helpful to explain the meaning of a "single TE domain." There=20 > is a passable=20 > definition in RFC 5212 section 1. TE domain is defined as group of LSRs that enforces a common TE policy.=20 > It would be worth clarifying whether a single TE domain can=20 > be served by=20 > more than one IGP instance. This is hinted at in section 5.7=20 > of RFC 5212. per 5212, we did even not limit it to single AS. for the specific question you ask wrt IGP, in a sense we bind applicability to IGP capability not the other way around. thanks, -d. > =3D=3D=3D >=20 > Thanks, > Adrian >=20 > ----- Original Message -----=20 > From: "PAPADIMITRIOU Dimitri"=20 > > To: > Sent: Monday, October 27, 2008 8:04 AM > Subject: MRN ext. doc >=20 >=20 > folks - >=20 > before asking for LC, we plan an update of this doc. see: >=20 > n-extensio > ns-02.txt> >=20 > please let us know if you see any missing description/holes in this > version (beside its IANA section). >=20 > thx, > -d. >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Oct 31 03:24:55 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 0C2823A6868 for ; Fri, 31 Oct 2008 03:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 xavKkp15uU3e for ; Fri, 31 Oct 2008 03:24:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B69A53A67E1 for ; Fri, 31 Oct 2008 03:24:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvr3F-0004uV-6M for ccamp-data@psg.com; Fri, 31 Oct 2008 10:16:21 +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 1Kvr33-0004tK-MG for ccamp@ops.ietf.org; Fri, 31 Oct 2008 10:16:15 +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 m9VAG0Pg005535; Fri, 31 Oct 2008 10:16:02 GMT 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 m9VAFx9Y005509; Fri, 31 Oct 2008 10:15:59 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , References: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> <8748264690F046B189E400061FE9FF7D@your029b8cecfe> <00275A5B436CA441900CB10936742A38014BA1CA@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: MRN ext. doc Date: Fri, 31 Oct 2008 10:15:53 -0000 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, Thanks. Closing on a couple of points... >> It would make sense for section 7 to reference >> draft-ietf-mpls-mpls-and-gmpls-security-framework > > do you have any specific point not covered by this section and covered > by the above ref. The IESG has repeatedly shown itself to be nervous about the security considerations of MPLS and GMPLS networks. Rather than be forced to reproduce a lot of material through a series of exchanges during IESG review and a sequence of updates to the draft at that stage, it seems pragmatic to include a reference to the general analysis of MPLS and GMPLS security. >> === >> We will definitely (well, very probably) be asked if we can show >> traceability back to the requirements. In fact, RFC 5339 >> includes section >> 4.1 that gives traceability from the evaluation back to the >> requirements. >> Section 2 of this document does not quite give the same level of >> traceability such that it is necessary to read most of 5339 >> to ensure that all requirements have been met. > > the current doc. covers the "delta" in terms of mechanism. so, do you > mean that mechanisms not requiring any extensions shall also be > included/described in this document ? Nope. Simply that the I-D should explicitly call out the lacunae identified in RFC 5339. For example, you could say... The following features are identified in [RFC5339] as requiring protocol extensions: 1. Feature to do something. See Section 1.2.3 of [RFC5339] 2. ... >> === >> Section 4 appears to consider only the mapped server model >> (allowing a many to one mapping), but not the multiplexed >> server model. Is it the intention to defer this to Section 5? > > i don't understand the question. Hmm. I'm using ITU terminology. Mapped server has a connection set up in the server layer "on demand" with only the bandwidth required by the client layer connection. Many-to-one mapped server allows that the server connection set up for a previous client layer connection may have "spare" bandwidth that can be allocated ("on demand") to support a further client layer connection. Multiplexed server model causes the "spare" bandwidth to be advertised in the client layer as a link. My question was trying to understand how the required function was split between the two sections 4 and 5. >> === >> Section 5 does not include reference to >> draft-ietf-ccamp-lsp-hierarchy-bis even though this is mentioned >> in RFC 5339. Shouldn't it? >> Actually, there is no mention in section 5 of using RFC 4206 >> procedures to set up FAs to form virtual TE links although that is >> clearly intended in 4206. > > referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206 I don't see any reference to draft-ietf-ccamp-lsp-hierarchy-bis in 5.1 or 5.2. Section 5.1 "relies on extensions to the GMPLS RSVP-TE Call procedure" so is not the same as the 4206 procedure. Section 5.2 is the "Soft FA approach" and although this could be achieved with modifications to the 4206 procedures, it is not the main purpose of the 4206 procedures. Perhaps the point is that *this* I-D is only providing additional functions not already described in other documents. If so, you can cover this whole point with a reminder at the top of section 5... This section describes additional features for the support of virtual TE links. The procedures described here complement those defined in [RFC4206] and [HIER-BIS]. >> === >> The Call-Attributes object C-Num is picked from the 11bbbbbb >> class. Why? >> Surely if any node that processes the Notify message does not >> understand the object, you want the Call to fail. > > this what has been agreed from last meeting. see Lou's preso. Well, it's wrong! :-) It doesn't make sense to use 11bbbbbb. Consider that you are using a Notify message that is targetted. Therefore, the first node to process the Notify message is the intended end point of the call, or a deliberate transit call controller. That means that we require the recipient to be able to process the object. Furthermore, there is nowhere for the message to be forwarded if the object is not understood. The special case of a Notify that is forwarded hop-by-hop does not require that the Call-Attributes object is processed since transit nodes "just forward the Notify message to the target node" without looking at the contents. We should use 0bbbbbbb >> === >> I'm puzzled that the Call described in section 5.1 does not >> indicate to the intended LSP egress in which layer or >> region the soon-to-be-set-up LSP will be required to >> operate. > > because > > - it is the FA setup that indicates to which bearer the virtual > link will be associated not the other way around > > - the virtual association is used by upper-region LSP so the virtual > link itself is an abstraction of the bearer/network (in other terms - > and by definition - one does not create Virtual TE links over Virtual > TE links) > > the only condition which can be verified from the TEDB is that both > ends of the bearer belongs to the same LSP region (symmetry). I meant... Suppose the head and tail of the planned virtual TE link are present in three regions (or layers, don't forget layers). One is the client, and two are potential servers. Shouldn't the call indicate which server the caller wishes/intends to use? >> === >> I don't find section 3.2.1 clear on the co-existence within >> the Link TLV of the IACD sub-TLV and the ISCD sub- >> TLV [RFC4203]. > > i will add a statement IACD does not modify format/messaging and > processing associated to the ISCD. Thanks. Now since there is a an aggregate duplication of information, what happens if the bandwidth cited in the IACD is greater than that in the ISCD? etc. Cheers, Adrian From owner-ccamp@ops.ietf.org Fri Oct 31 03:50: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 39F5A3A6BAC for ; Fri, 31 Oct 2008 03:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.245, 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 f1NZpDn233rP for ; Fri, 31 Oct 2008 03:50:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CFD93A6B75 for ; Fri, 31 Oct 2008 03:50:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvrVD-0007aV-Ks for ccamp-data@psg.com; Fri, 31 Oct 2008 10:45:15 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvrUz-0007ZG-DU for ccamp@ops.ietf.org; Fri, 31 Oct 2008 10:45:08 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 718B43A6BA6; Fri, 31 Oct 2008 03: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-spc-rsvpte-ext-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081031104501.718B43A6BA6@core3.amsl.com> Date: Fri, 31 Oct 2008 03:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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-spc-rsvpte-ext-02.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt Pages : 23 Date : 2008-10-31 We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. See draft "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. Failure conductions and subsequent roll back are also illustrated taking into account that an handover failure must not impact the already established data plane connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-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-pc-spc-rsvpte-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31033037.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Fri Oct 31 06:13: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 412023A69A1 for ; Fri, 31 Oct 2008 06:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.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] 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 s4OZKiyz22Lt for ; Fri, 31 Oct 2008 06:13:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16AC63A68C3 for ; Fri, 31 Oct 2008 06:13:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvtiV-000LDe-6T for ccamp-data@psg.com; Fri, 31 Oct 2008 13:07:07 +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 1KvtiG-000LCA-1L for ccamp@ops.ietf.org; Fri, 31 Oct 2008 13:07:01 +0000 X-IronPort-AV: E=Sophos;i="4.33,522,1220227200"; d="scan'208,217";a="24311018" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2008 13:06:50 +0000 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 m9VD6o0f031991; Fri, 31 Oct 2008 14:06:50 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9VD6oki001706; Fri, 31 Oct 2008 13:06:50 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 14:06:50 +0100 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_01C93B59.8955C5E2" Subject: RE: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wgdoc Date: Fri, 31 Oct 2008 14:06:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wgdoc Thread-Index: Ack7WS9EhpS4syAKQEaSSiFm9mSLLwAAFSU+ References: <4906E57E.4050105@pi.nu> From: "Monique Morrow (mmorrow)" To: "Andrew G. Malis" , "Loa Andersson" Cc: "ccamp" , , "pwe3" , X-OriginalArrivalTime: 31 Oct 2008 13:06:50.0169 (UTC) FILETIME=[897EDA90:01C93B59] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4841; t=1225458410; x=1226322410; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmorrow@cisco.com; z=From:=20=22Monique=20Morrow=20(mmorrow)=22=20 |Subject:=20RE=3A=20[mpls]=20[PWE3]=20draft-bocci-mpls-tp-g ach-gal-00.txt=20for=20mpls=20wgdoc |Sender:=20; bh=QJ2uxLl5H1+VTYJheR1xc2PXUCi/Xy6zo5KBu9c8JdU=; b=jp1/c5oHZhp+GYShSpWEp6KZIMTzWNWNbepe6uMIHBg9mHZM0vsLgsGQJf B75q4txzhiXkQ6Hj93iOch73wwACF3tx/+bIkEpscs/+tDn5qH8XeLPPyVn+ YAjYidbakH; Authentication-Results: ams-dkim-2; header.From=mmorrow@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B59.8955C5E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Also support Monique Jeanne Morrow SP APAC CTO/Distinguished Consulting Engineer -----Original Message----- From: mpls-bounces@ietf.org on behalf of Andrew G. Malis Sent: Fri 10/31/2008 6:02 AM To: Loa Andersson Cc: ccamp; mpls@ietf.org; pwe3; ahtmpls@itu.int Subject: Re: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls = wgdoc =20 Support. On Tue, Oct 28, 2008 at 6:12 AM, Loa Andersson wrote: > Working group(s), > > this is to initiate a two week poll to see if > draft-bocci-mpls-tp-gach-gal-00.txt is in shape to > become a mpls working group document. > > The current draft is a merge of to earlier draft > one that defined the GAL and another that specified > the generic associated channel. > > Please send your responses to the mpls working group > mailing list (needs a bit of discipline, "replay all" > won't do the trick ;) . > > Please respond on Tuesday Oct 11 the latest. > > /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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01C93B59.8955C5E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls = wgdoc

Also support

Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer



-----Original Message-----
From: mpls-bounces@ietf.org on behalf of Andrew G. Malis
Sent: Fri 10/31/2008 6:02 AM
To: Loa Andersson
Cc: ccamp; mpls@ietf.org; pwe3; ahtmpls@itu.int
Subject: Re: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls = wgdoc

Support.

On Tue, Oct 28, 2008 at 6:12 AM, Loa Andersson <loa@pi.nu> = wrote:
> Working group(s),
>
> this is to initiate a two week poll to see if
> draft-bocci-mpls-tp-gach-gal-00.txt is in shape to
> become a mpls working group document.
>
> The current draft is a merge of to earlier draft
> one that defined the GAL and another that specified
> the generic associated channel.
>
> Please send your responses to the mpls working group
> mailing list (needs a bit of discipline, "replay all"
> won't do the trick ;) .
>
> Please respond on Tuesday Oct 11 the latest.
>
> /Loa
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo = AB            = ;            =    phone:  +46 8 632 77 14
> Isafjordsgatan = 22            = ;      mobile: +46 739 81 21 64
> Kista, = Sweden           &= nbsp;          email:  = loa.andersson@acreo.se
>           &nb= sp;           &nbs= p;            = ;       loa@pi.nu
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/= mailman/listinfo/pwe3
>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/= mailman/listinfo/mpls

------_=_NextPart_001_01C93B59.8955C5E2-- From owner-ccamp@ops.ietf.org Fri Oct 31 07:58: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 BC42C28C158 for ; Fri, 31 Oct 2008 07:58:44 -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 Ni5erZ-TaH3d for ; Fri, 31 Oct 2008 07:58:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F64E3A6B74 for ; Fri, 31 Oct 2008 07:58:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvvN1-0006jo-Dh for ccamp-data@psg.com; Fri, 31 Oct 2008 14:53:03 +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 1KvvMo-0006ib-2R for ccamp@ops.ietf.org; Fri, 31 Oct 2008 14:52:58 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-12.tower-203.messagelabs.com!1225464767!21955375!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23472 invoked from network); 31 Oct 2008 14:52:48 -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; 31 Oct 2008 14:52:48 -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 m9VEqlNp015254; Fri, 31 Oct 2008 10:52:47 -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 m9VEqdtR015182; Fri, 31 Oct 2008 10:52:40 -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_01C93B68.521383E4" Subject: Please publish draft-ietf-ccamp-gr-description-03.txt Date: Fri, 31 Oct 2008 10:52:38 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-gr-description-03.txt Thread-Index: Ack7aFGhZoJTSOlYSCK3osmAbD5lsg== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B68.521383E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-gr-description-03 Intended status : Informational > (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? This document has been reviewed by the CCAMP working group and received some comments at IETF meetings and on the mailing list. Most importantly it has had input from the authors of RFC 5063 that documents the protocol procedures. > (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. The document is sound. No IPR disclosures 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? There were no problems with consensus for this document. > (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 downrefs. > (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? This is an Informational I-D that makes no requestes of IANA. A Null IANA section is included. > (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 formal language 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. 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. GMPLS protocol definitions for RSVP also allow a restarting node to learn the label that it previously allocated for use on a Label Switching Path (LSP). Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors. This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different. This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. > Working Group Summary > 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? There was some debate about the need for this work. It was suggested that all of the necessary explanation of the operation of graceful restart was included in RFC 5063. However, the repeated questions about how to use the protocol extensions in corner cases and double faliure scenarios makes this work valuable. Otherwise, all parts of the WG process were normal. > 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 several implementations of the graceful restart processes described in RFC 5063. Experience from these implementations has provided valuable input to this document. ------_=_NextPart_001_01C93B68.521383E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Proto-write-up for =
draft-ietf-ccamp-gr-description-03

Intended status : Informational

> (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?

This document has been reviewed by the CCAMP working group and received
some comments at IETF meetings and on the mailing list. Most importantly
it has had input from the authors of RFC 5063 that documents the
protocol procedures.

> (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.

The document is sound.
No IPR disclosures 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?

There were no problems with consensus for this document.


> (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 downrefs.

> (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?

This is an Informational I-D that makes no requestes of IANA.
A Null IANA section is included.

> (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 formal language 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.

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.

GMPLS protocol definitions for RSVP also allow a restarting node to
learn the label that it previously allocated for use on a Label
Switching Path (LSP).

Further RSVP protocol extensions have been defined to enable a
restarting node to recover full control plane state by exchanging
RSVP messages with its upstream and downstream neighbors.

This document provides an informational clarification of the
control plane procedures for a GMPLS network when there are
multiple node failures, and describes how full control plane state
can be recovered in different scenarios where the order in which
the nodes restart is different.

This document does not define any new processes or procedures. All
protocol mechanisms are already defined in the referenced documents.

>        Working Group Summary
>           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?

There was some debate about the need for this work. It was suggested
that all of the necessary explanation of the operation of graceful
restart was included in RFC 5063. However, the repeated questions about
how to use the protocol extensions in corner cases and double faliure
scenarios makes this work valuable.

Otherwise, all parts of the WG process were normal.

>        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 several implementations of the graceful restart processes
described in RFC 5063. Experience from these implementations has
provided valuable input to this document.
------_=_NextPart_001_01C93B68.521383E4-- From owner-ccamp@ops.ietf.org Fri Oct 31 08:06: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 F145D3A6C10 for ; Fri, 31 Oct 2008 08:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.141 X-Spam-Level: X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[AWL=-0.874, 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 t4CnoAZlLhFn for ; Fri, 31 Oct 2008 08:06:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B65FF3A6BDE for ; Fri, 31 Oct 2008 08:05:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvvUz-0007jr-M3 for ccamp-data@psg.com; Fri, 31 Oct 2008 15:01:17 +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 1KvvUo-0007ih-7G for ccamp@ops.ietf.org; Fri, 31 Oct 2008 15:01:11 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-10.tower-203.messagelabs.com!1225465264!17586171!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 28989 invoked from network); 31 Oct 2008 15:01:05 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-10.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 31 Oct 2008 15:01:05 -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 m9VF13qC021747; Fri, 31 Oct 2008 11:01:04 -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 m9VF0tej021621; Fri, 31 Oct 2008 11:00:55 -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_01C93B69.59C36647" Subject: Please publish draft-ietf-ccamp-pc-and-sc-reqs-06.txt Date: Fri, 31 Oct 2008 11:00:01 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-pc-and-sc-reqs-06.txt Thread-Index: Ack7aVlYnJ+v9I7gRo2fHz8dBYfTdw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B69.59C36647 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-pc-and-sc-reqs-06 Intended status : Informational > (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? This document has been reviewed by the CCAMP working group and received good discussion on the mailiing list and at IETF meetings. No concerns about the level of review. > (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. The document is sound. No IPR disclosures 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? There were no problems with consensus for this document. In the early stages there were some very strong opinions about the value of this work. Some vendors and operators did not believe that the function would be useful in the networks they build. However, over time, other vendors and operators strongly supported the function, and since it is described as an optional function in equipment and deployment, the working group did not object to this work proceeding. > (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 downrefs. > (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? This is an Informational I-D that makes no requestes of IANA. A Null IANA section is included. > (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 formal language 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. >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. In the context of GMPLS, this can be seen as setting up control plane state for an LSP that was itself established using management intervention at each node along the path. Also included is the converse process of removing control plane state for an LSP so that the traffic is not disrupted and ownership of the LSP is passed to the management plane. This document sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. > Working Group Summary > 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? Nothing of note. > 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? This is a requirements specification, and cannot be implemented. Note that work is already in progress within the CCAMP working group to develop protocol solutions. ------_=_NextPart_001_01C93B69.59C36647 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Proto-write-up for draft-ietf-ccamp-pc-and-sc-reqs-06

Intended status : Informational

> (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?

This document has been reviewed by the CCAMP working group and received
good discussion on the mailiing list and at IETF meetings. No concerns
about the level of review.

> (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.

The document is sound.
No IPR disclosures 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?

There were no problems with consensus for this document.

In the early stages there were some very strong opinions about the
value of this work. Some vendors and operators did not believe that the
function would be useful in the networks they build. However, over time,
other vendors and operators strongly supported the function, and since
it is described as an optional function in equipment and deployment, the
working group did not object to this work proceeding.

> (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 downrefs.

> (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?

This is an Informational I-D that makes no requestes of IANA.
A Null IANA section is included.

> (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 formal language 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.

>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.

In the context of GMPLS, this can be seen as setting up control plane
state for an LSP that was itself established using management
intervention at each node along the path. Also included is the converse
process of removing control plane state for an LSP so that the traffic
is not disrupted and ownership of the LSP is passed to the management
plane.

This document sets out the =
requirements for such procedures within a
Generalized Multiprotocol Label Switching (GMPLS) network.

>        Working Group Summary
>           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?

Nothing of note.

>        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?

This is a requirements specification, and cannot be implemented. Note
that work is already in progress within the CCAMP working group to
develop protocol solutions.
------_=_NextPart_001_01C93B69.59C36647-- From owner-ccamp@ops.ietf.org Fri Oct 31 10:59: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 352DC3A6C09 for ; Fri, 31 Oct 2008 10:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[AWL=1.754, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=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 z8mkBeBicSPw for ; Fri, 31 Oct 2008 10:59:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B92C63A677C for ; Fri, 31 Oct 2008 10:59:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvy9C-0001tU-25 for ccamp-data@psg.com; Fri, 31 Oct 2008 17:50:58 +0000 Received: from [62.23.212.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kvy91-0001s6-9I for ccamp@ops.ietf.org; Fri, 31 Oct 2008 17:50:52 +0000 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m9VHohCi017795; Fri, 31 Oct 2008 18:50:43 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 31 Oct 2008 18:50:43 +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: MRN ext. doc Date: Fri, 31 Oct 2008 18:50:42 +0100 Message-ID: <00275A5B436CA441900CB10936742A38014BA4AF@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MRN ext. doc Thread-Index: Ack7QbZg/d2Mlt7bSoGToRLlVW7lpgACXGeQ References: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> <8748264690F046B189E400061FE9FF7D@your029b8cecfe> <00275A5B436CA441900CB10936742A38014BA1CA@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 31 Oct 2008 17:50:43.0534 (UTC) FILETIME=[322C16E0:01C93B81] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: adrian=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, October 31, 2008 11:16 AM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: MRN ext. doc >=20 > Hi, >=20 > Thanks. >=20 > Closing on a couple of points... >=20 > >> It would make sense for section 7 to reference > >> draft-ietf-mpls-mpls-and-gmpls-security-framework > > > > do you have any specific point not covered by this section=20 > and covered > > by the above ref. >=20 > The IESG has repeatedly shown itself to be nervous about the security=20 > considerations of MPLS and GMPLS networks. Rather than be forced to=20 > reproduce a lot of material through a series of exchanges=20 > during IESG review=20 > and a sequence of updates to the draft at that stage, it=20 > seems pragmatic to=20 > include a reference to the general analysis of MPLS and GMPLS=20 > security. >=20 > >> =3D=3D=3D > >> We will definitely (well, very probably) be asked if we can show > >> traceability back to the requirements. In fact, RFC 5339 > >> includes section > >> 4.1 that gives traceability from the evaluation back to the > >> requirements. > >> Section 2 of this document does not quite give the same level of > >> traceability such that it is necessary to read most of 5339 > >> to ensure that all requirements have been met. > > > > the current doc. covers the "delta" in terms of mechanism.=20 > so, do you > > mean that mechanisms not requiring any extensions shall also be > > included/described in this document ? >=20 > Nope. > Simply that the I-D should explicitly call out the lacunae=20 > identified in RFC=20 > 5339. > For example, you could say... > The following features are identified in [RFC5339] as=20 > requiring protocol=20 > extensions: > 1. Feature to do something. See Section 1.2.3 of [RFC5339] > 2. ... ok - you would like a ref. to 5339. > >> =3D=3D=3D > >> Section 4 appears to consider only the mapped server model > >> (allowing a many to one mapping), but not the multiplexed > >> server model. Is it the intention to defer this to Section 5? > > > > i don't understand the question. >=20 > Hmm. I'm using ITU terminology. > Mapped server has a connection set up in the server layer "on=20 > demand" with=20 > only the bandwidth required by the client layer connection. > Many-to-one mapped server allows that the server connection=20 > set up for a=20 > previous client layer connection may have "spare" bandwidth=20 > that can be=20 > allocated ("on demand") to support a further client layer connection. > Multiplexed server model causes the "spare" bandwidth to be=20 > advertised in=20 > the client layer as a link. >=20 > My question was trying to understand how the required=20 > function was split=20 > between the two sections 4 and 5. can u please use the ietf terminology at least to make the point understandable to me (excuse my ignorance). what is a mapped server ? > >> =3D=3D=3D > >> Section 5 does not include reference to > >> draft-ietf-ccamp-lsp-hierarchy-bis even though this is mentioned > >> in RFC 5339. Shouldn't it? > >> Actually, there is no mention in section 5 of using RFC 4206 > >> procedures to set up FAs to form virtual TE links although that is > >> clearly intended in 4206. > > > > referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206 >=20 > I don't see any reference to=20 > draft-ietf-ccamp-lsp-hierarchy-bis in 5.1 or=20 > 5.2. >=20 > Section 5.1 "relies on extensions to the GMPLS RSVP-TE Call=20 > procedure" so is=20 > not the same as the 4206 procedure. >=20 > Section 5.2 is the "Soft FA approach" and although this could=20 > be achieved=20 > with modifications to the 4206 procedures, it is not the main=20 > purpose of the=20 > 4206 procedures. >=20 > Perhaps the point is that *this* I-D is only providing=20 > additional functions=20 > not already described in other documents. If so, you can=20 > cover this whole=20 > point with a reminder at the top of section 5... > This section describes additional features for the support of > virtual TE links. The procedures described here complement > those defined in [RFC4206] and [HIER-BIS]. yes, they "complement" is that not the definition of an extension ? > >> =3D=3D=3D > >> The Call-Attributes object C-Num is picked from the 11bbbbbb > >> class. Why? > >> Surely if any node that processes the Notify message does not > >> understand the object, you want the Call to fail. > > > > this what has been agreed from last meeting. see Lou's preso. >=20 > Well, it's wrong! :-) >=20 > It doesn't make sense to use 11bbbbbb. > Consider that you are using a Notify message that is=20 > targetted. Therefore,=20 > the first node to process the Notify message is the intended=20 > end point of=20 > the call, or a deliberate transit call controller. That means that we=20 > require the recipient to be able to process the object.=20 > Furthermore, there=20 > is nowhere for the message to be forwarded if the object is=20 > not understood. not sure. at the end the question is an attribute object class a criteria for which rejection is expected. going one step further one can mandate support of the class but it is the support of the associated capability that matters.. one would be still blocking on the latter anyway if that capability would not be supported independently of the object class. so it is the "mandatory or optional" nature of the attribute that induce support of the object not the other way around.=20 =20 > The special case of a Notify that is forwarded hop-by-hop=20 > does not require=20 > that the Call-Attributes object is processed since transit=20 > nodes "just=20 > forward the Notify message to the target node" without looking at the=20 > contents. > > We should use 0bbbbbbb >=20 > >> =3D=3D=3D > >> I'm puzzled that the Call described in section 5.1 does not > >> indicate to the intended LSP egress in which layer or > >> region the soon-to-be-set-up LSP will be required to > >> operate. > > > > because > > > > - it is the FA setup that indicates to which bearer the virtual > > link will be associated not the other way around > > > > - the virtual association is used by upper-region LSP so the virtual > > link itself is an abstraction of the bearer/network (in=20 > other terms - > > and by definition - one does not create Virtual TE links=20 > over Virtual > > TE links) > > > > the only condition which can be verified from the TEDB is that both > > ends of the bearer belongs to the same LSP region (symmetry). >=20 > I meant... > Suppose the head and tail of the planned virtual TE link are=20 > present in=20 > three regions (or layers, don't forget layers). One is the=20 > client, and two=20 > are potential servers. > Shouldn't the call indicate which server the caller=20 > wishes/intends to use? assume a base virtual TE link [PSC,PSC] and the two link sequence that can be followed by the FA-LSP are either [PSC,LSC]..[LSC,LSC]..[LSC,PSC] or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association between the TE link and LSP that determines to which FA that TE link is now related to > >> =3D=3D=3D > >> I don't find section 3.2.1 clear on the co-existence within > >> the Link TLV of the IACD sub-TLV and the ISCD sub- > >> TLV [RFC4203]. > > > > i will add a statement IACD does not modify format/messaging and > > processing associated to the ISCD. >=20 > Thanks. >=20 > Now since there is a an aggregate duplication of information where do you see the "duplication" of information b/w IACD and ISCD ? =20 thanks, -d. > what happens=20 > if the bandwidth cited in the IACD is greater than that in=20 > the ISCD? etc. > > Cheers, > Adrian=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Oct 31 15:51: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 8A8B43A67B2 for ; Fri, 31 Oct 2008 15:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.240, 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 SoJOrvQNwYxm for ; Fri, 31 Oct 2008 15:51:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD06F3A6802 for ; Fri, 31 Oct 2008 15:51:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kw2js-0004RM-Hf for ccamp-data@psg.com; Fri, 31 Oct 2008 22:45:08 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kw2jl-0004QM-AQ for ccamp@ops.ietf.org; Fri, 31 Oct 2008 22:45:04 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 477F63A6A99; Fri, 31 Oct 2008 15: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-wavelength-switched-framework-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081031224501.477F63A6A99@core3.amsl.com> Date: Fri, 31 Oct 2008 15:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 Filename : draft-ietf-ccamp-wavelength-switched-framework-01.txt Pages : 37 Date : 2008-10-31 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-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-wavelength-switched-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31154129.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 22:47:13 +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-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081031224501.477F63A6A99@core3.amsl.com> Date: Fri, 31 Oct 2008 15: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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-wavelength-switched-framework-01.txt Pages : 37 Date : 2008-10-31 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-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-wavelength-switched-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31154129.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 17:52:54 +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: MRN ext. doc Date: Fri, 31 Oct 2008 18:50:42 +0100 Message-ID: <00275A5B436CA441900CB10936742A38014BA4AF@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: MRN ext. doc Thread-Index: Ack7QbZg/d2Mlt7bSoGToRLlVW7lpgACXGeQ From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , adrian=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, October 31, 2008 11:16 AM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: MRN ext. doc >=20 > Hi, >=20 > Thanks. >=20 > Closing on a couple of points... >=20 > >> It would make sense for section 7 to reference > >> draft-ietf-mpls-mpls-and-gmpls-security-framework > > > > do you have any specific point not covered by this section=20 > and covered > > by the above ref. >=20 > The IESG has repeatedly shown itself to be nervous about the security=20 > considerations of MPLS and GMPLS networks. Rather than be forced to=20 > reproduce a lot of material through a series of exchanges=20 > during IESG review=20 > and a sequence of updates to the draft at that stage, it=20 > seems pragmatic to=20 > include a reference to the general analysis of MPLS and GMPLS=20 > security. >=20 > >> =3D=3D=3D > >> We will definitely (well, very probably) be asked if we can show > >> traceability back to the requirements. In fact, RFC 5339 > >> includes section > >> 4.1 that gives traceability from the evaluation back to the > >> requirements. > >> Section 2 of this document does not quite give the same level of > >> traceability such that it is necessary to read most of 5339 > >> to ensure that all requirements have been met. > > > > the current doc. covers the "delta" in terms of mechanism.=20 > so, do you > > mean that mechanisms not requiring any extensions shall also be > > included/described in this document ? >=20 > Nope. > Simply that the I-D should explicitly call out the lacunae=20 > identified in RFC=20 > 5339. > For example, you could say... > The following features are identified in [RFC5339] as=20 > requiring protocol=20 > extensions: > 1. Feature to do something. See Section 1.2.3 of [RFC5339] > 2. ... ok - you would like a ref. to 5339. > >> =3D=3D=3D > >> Section 4 appears to consider only the mapped server model > >> (allowing a many to one mapping), but not the multiplexed > >> server model. Is it the intention to defer this to Section 5? > > > > i don't understand the question. >=20 > Hmm. I'm using ITU terminology. > Mapped server has a connection set up in the server layer "on=20 > demand" with=20 > only the bandwidth required by the client layer connection. > Many-to-one mapped server allows that the server connection=20 > set up for a=20 > previous client layer connection may have "spare" bandwidth=20 > that can be=20 > allocated ("on demand") to support a further client layer connection. > Multiplexed server model causes the "spare" bandwidth to be=20 > advertised in=20 > the client layer as a link. >=20 > My question was trying to understand how the required=20 > function was split=20 > between the two sections 4 and 5. can u please use the ietf terminology at least to make the point understandable to me (excuse my ignorance). what is a mapped server ? > >> =3D=3D=3D > >> Section 5 does not include reference to > >> draft-ietf-ccamp-lsp-hierarchy-bis even though this is mentioned > >> in RFC 5339. Shouldn't it? > >> Actually, there is no mention in section 5 of using RFC 4206 > >> procedures to set up FAs to form virtual TE links although that is > >> clearly intended in 4206. > > > > referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206 >=20 > I don't see any reference to=20 > draft-ietf-ccamp-lsp-hierarchy-bis in 5.1 or=20 > 5.2. >=20 > Section 5.1 "relies on extensions to the GMPLS RSVP-TE Call=20 > procedure" so is=20 > not the same as the 4206 procedure. >=20 > Section 5.2 is the "Soft FA approach" and although this could=20 > be achieved=20 > with modifications to the 4206 procedures, it is not the main=20 > purpose of the=20 > 4206 procedures. >=20 > Perhaps the point is that *this* I-D is only providing=20 > additional functions=20 > not already described in other documents. If so, you can=20 > cover this whole=20 > point with a reminder at the top of section 5... > This section describes additional features for the support of > virtual TE links. The procedures described here complement > those defined in [RFC4206] and [HIER-BIS]. yes, they "complement" is that not the definition of an extension ? > >> =3D=3D=3D > >> The Call-Attributes object C-Num is picked from the 11bbbbbb > >> class. Why? > >> Surely if any node that processes the Notify message does not > >> understand the object, you want the Call to fail. > > > > this what has been agreed from last meeting. see Lou's preso. >=20 > Well, it's wrong! :-) >=20 > It doesn't make sense to use 11bbbbbb. > Consider that you are using a Notify message that is=20 > targetted. Therefore,=20 > the first node to process the Notify message is the intended=20 > end point of=20 > the call, or a deliberate transit call controller. That means that we=20 > require the recipient to be able to process the object.=20 > Furthermore, there=20 > is nowhere for the message to be forwarded if the object is=20 > not understood. not sure. at the end the question is an attribute object class a criteria for which rejection is expected. going one step further one can mandate support of the class but it is the support of the associated capability that matters.. one would be still blocking on the latter anyway if that capability would not be supported independently of the object class. so it is the "mandatory or optional" nature of the attribute that induce support of the object not the other way around.=20 =20 > The special case of a Notify that is forwarded hop-by-hop=20 > does not require=20 > that the Call-Attributes object is processed since transit=20 > nodes "just=20 > forward the Notify message to the target node" without looking at the=20 > contents. > > We should use 0bbbbbbb >=20 > >> =3D=3D=3D > >> I'm puzzled that the Call described in section 5.1 does not > >> indicate to the intended LSP egress in which layer or > >> region the soon-to-be-set-up LSP will be required to > >> operate. > > > > because > > > > - it is the FA setup that indicates to which bearer the virtual > > link will be associated not the other way around > > > > - the virtual association is used by upper-region LSP so the virtual > > link itself is an abstraction of the bearer/network (in=20 > other terms - > > and by definition - one does not create Virtual TE links=20 > over Virtual > > TE links) > > > > the only condition which can be verified from the TEDB is that both > > ends of the bearer belongs to the same LSP region (symmetry). >=20 > I meant... > Suppose the head and tail of the planned virtual TE link are=20 > present in=20 > three regions (or layers, don't forget layers). One is the=20 > client, and two=20 > are potential servers. > Shouldn't the call indicate which server the caller=20 > wishes/intends to use? assume a base virtual TE link [PSC,PSC] and the two link sequence that can be followed by the FA-LSP are either [PSC,LSC]..[LSC,LSC]..[LSC,PSC] or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association between the TE link and LSP that determines to which FA that TE link is now related to > >> =3D=3D=3D > >> I don't find section 3.2.1 clear on the co-existence within > >> the Link TLV of the IACD sub-TLV and the ISCD sub- > >> TLV [RFC4203]. > > > > i will add a statement IACD does not modify format/messaging and > > processing associated to the ISCD. >=20 > Thanks. >=20 > Now since there is a an aggregate duplication of information where do you see the "duplication" of information b/w IACD and ISCD ? =20 thanks, -d. > what happens=20 > if the bandwidth cited in the IACD is greater than that in=20 > the ISCD? etc. > > Cheers, > Adrian=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 15:01:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93B69.59C36647" Subject: Please publish draft-ietf-ccamp-pc-and-sc-reqs-06.txt Date: Fri, 31 Oct 2008 11:00:01 -0400 Message-ID: Thread-Topic: Please publish draft-ietf-ccamp-pc-and-sc-reqs-06.txt Thread-Index: Ack7aVlYnJ+v9I7gRo2fHz8dBYfTdw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B69.59C36647 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-pc-and-sc-reqs-06 Intended status : Informational > (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? This document has been reviewed by the CCAMP working group and received good discussion on the mailiing list and at IETF meetings. No concerns about the level of review. > (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. The document is sound. No IPR disclosures 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? There were no problems with consensus for this document. In the early stages there were some very strong opinions about the value of this work. Some vendors and operators did not believe that the function would be useful in the networks they build. However, over time, other vendors and operators strongly supported the function, and since it is described as an optional function in equipment and deployment, the working group did not object to this work proceeding. > (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 downrefs. > (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? This is an Informational I-D that makes no requestes of IANA. A Null IANA section is included. > (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 formal language 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. >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. In the context of GMPLS, this can be seen as setting up control plane state for an LSP that was itself established using management intervention at each node along the path. Also included is the converse process of removing control plane state for an LSP so that the traffic is not disrupted and ownership of the LSP is passed to the management plane. This document sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. > Working Group Summary > 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? Nothing of note. > 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? This is a requirements specification, and cannot be implemented. Note that work is already in progress within the CCAMP working group to develop protocol solutions. ------_=_NextPart_001_01C93B69.59C36647 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Proto-write-up for draft-ietf-ccamp-pc-and-sc-reqs-06

Intended status : Informational

> (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?

This document has been reviewed by the CCAMP working group and received
good discussion on the mailiing list and at IETF meetings. No concerns
about the level of review.

> (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.

The document is sound.
No IPR disclosures 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?

There were no problems with consensus for this document.

In the early stages there were some very strong opinions about the
value of this work. Some vendors and operators did not believe that the
function would be useful in the networks they build. However, over time,
other vendors and operators strongly supported the function, and since
it is described as an optional function in equipment and deployment, the
working group did not object to this work proceeding.

> (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 downrefs.

> (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?

This is an Informational I-D that makes no requestes of IANA.
A Null IANA section is included.

> (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 formal language 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.

>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.

In the context of GMPLS, this can be seen as setting up control plane
state for an LSP that was itself established using management
intervention at each node along the path. Also included is the converse
process of removing control plane state for an LSP so that the traffic
is not disrupted and ownership of the LSP is passed to the management
plane.

This document sets out the =
requirements for such procedures within a
Generalized Multiprotocol Label Switching (GMPLS) network.

>        Working Group Summary
>           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?

Nothing of note.

>        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?

This is a requirements specification, and cannot be implemented. Note
that work is already in progress within the CCAMP working group to
develop protocol solutions.
------_=_NextPart_001_01C93B69.59C36647-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 14:54:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93B68.521383E4" Subject: Please publish draft-ietf-ccamp-gr-description-03.txt Date: Fri, 31 Oct 2008 10:52:38 -0400 Message-ID: Thread-Topic: Please publish draft-ietf-ccamp-gr-description-03.txt Thread-Index: Ack7aFGhZoJTSOlYSCK3osmAbD5lsg== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B68.521383E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-gr-description-03 Intended status : Informational > (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? This document has been reviewed by the CCAMP working group and received some comments at IETF meetings and on the mailing list. Most importantly it has had input from the authors of RFC 5063 that documents the protocol procedures. > (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. The document is sound. No IPR disclosures 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? There were no problems with consensus for this document. > (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 downrefs. > (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? This is an Informational I-D that makes no requestes of IANA. A Null IANA section is included. > (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 formal language 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. 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. GMPLS protocol definitions for RSVP also allow a restarting node to learn the label that it previously allocated for use on a Label Switching Path (LSP). Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors. This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different. This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. > Working Group Summary > 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? There was some debate about the need for this work. It was suggested that all of the necessary explanation of the operation of graceful restart was included in RFC 5063. However, the repeated questions about how to use the protocol extensions in corner cases and double faliure scenarios makes this work valuable. Otherwise, all parts of the WG process were normal. > 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 several implementations of the graceful restart processes described in RFC 5063. Experience from these implementations has provided valuable input to this document. ------_=_NextPart_001_01C93B68.521383E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Proto-write-up for =
draft-ietf-ccamp-gr-description-03

Intended status : Informational

> (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?

This document has been reviewed by the CCAMP working group and received
some comments at IETF meetings and on the mailing list. Most importantly
it has had input from the authors of RFC 5063 that documents the
protocol procedures.

> (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.

The document is sound.
No IPR disclosures 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?

There were no problems with consensus for this document.


> (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 downrefs.

> (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?

This is an Informational I-D that makes no requestes of IANA.
A Null IANA section is included.

> (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 formal language 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.

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.

GMPLS protocol definitions for RSVP also allow a restarting node to
learn the label that it previously allocated for use on a Label
Switching Path (LSP).

Further RSVP protocol extensions have been defined to enable a
restarting node to recover full control plane state by exchanging
RSVP messages with its upstream and downstream neighbors.

This document provides an informational clarification of the
control plane procedures for a GMPLS network when there are
multiple node failures, and describes how full control plane state
can be recovered in different scenarios where the order in which
the nodes restart is different.

This document does not define any new processes or procedures. All
protocol mechanisms are already defined in the referenced documents.

>        Working Group Summary
>           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?

There was some debate about the need for this work. It was suggested
that all of the necessary explanation of the operation of graceful
restart was included in RFC 5063. However, the repeated questions about
how to use the protocol extensions in corner cases and double faliure
scenarios makes this work valuable.

Otherwise, all parts of the WG process were normal.

>        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 several implementations of the graceful restart processes
described in RFC 5063. Experience from these implementations has
provided valuable input to this document.
------_=_NextPart_001_01C93B68.521383E4-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 13:09:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93B59.8955C5E2" Subject: RE: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wgdoc Date: Fri, 31 Oct 2008 14:06:40 +0100 Message-ID: Thread-Topic: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wgdoc Thread-Index: Ack7WS9EhpS4syAKQEaSSiFm9mSLLwAAFSU+ From: "Monique Morrow (mmorrow)" To: "Andrew G. Malis" , "Loa Andersson" Cc: "ccamp" , , "pwe3" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4841; t=1225458410; x=1226322410; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmorrow@cisco.com; z=From:=20=22Monique=20Morrow=20(mmorrow)=22=20 |Subject:=20RE=3A=20[mpls]=20[PWE3]=20draft-bocci-mpls-tp-g ach-gal-00.txt=20for=20mpls=20wgdoc |Sender:=20; bh=QJ2uxLl5H1+VTYJheR1xc2PXUCi/Xy6zo5KBu9c8JdU=; b=jp1/c5oHZhp+GYShSpWEp6KZIMTzWNWNbepe6uMIHBg9mHZM0vsLgsGQJf B75q4txzhiXkQ6Hj93iOch73wwACF3tx/+bIkEpscs/+tDn5qH8XeLPPyVn+ YAjYidbakH; Authentication-Results: ams-dkim-2; header.From=mmorrow@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B59.8955C5E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Also support Monique Jeanne Morrow SP APAC CTO/Distinguished Consulting Engineer -----Original Message----- From: mpls-bounces@ietf.org on behalf of Andrew G. Malis Sent: Fri 10/31/2008 6:02 AM To: Loa Andersson Cc: ccamp; mpls@ietf.org; pwe3; ahtmpls@itu.int Subject: Re: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls = wgdoc =20 Support. On Tue, Oct 28, 2008 at 6:12 AM, Loa Andersson wrote: > Working group(s), > > this is to initiate a two week poll to see if > draft-bocci-mpls-tp-gach-gal-00.txt is in shape to > become a mpls working group document. > > The current draft is a merge of to earlier draft > one that defined the GAL and another that specified > the generic associated channel. > > Please send your responses to the mpls working group > mailing list (needs a bit of discipline, "replay all" > won't do the trick ;) . > > Please respond on Tuesday Oct 11 the latest. > > /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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01C93B59.8955C5E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls = wgdoc

Also support

Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer



-----Original Message-----
From: mpls-bounces@ietf.org on behalf of Andrew G. Malis
Sent: Fri 10/31/2008 6:02 AM
To: Loa Andersson
Cc: ccamp; mpls@ietf.org; pwe3; ahtmpls@itu.int
Subject: Re: [mpls] [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls = wgdoc

Support.

On Tue, Oct 28, 2008 at 6:12 AM, Loa Andersson <loa@pi.nu> = wrote:
> Working group(s),
>
> this is to initiate a two week poll to see if
> draft-bocci-mpls-tp-gach-gal-00.txt is in shape to
> become a mpls working group document.
>
> The current draft is a merge of to earlier draft
> one that defined the GAL and another that specified
> the generic associated channel.
>
> Please send your responses to the mpls working group
> mailing list (needs a bit of discipline, "replay all"
> won't do the trick ;) .
>
> Please respond on Tuesday Oct 11 the latest.
>
> /Loa
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo = AB            = ;            =    phone:  +46 8 632 77 14
> Isafjordsgatan = 22            = ;      mobile: +46 739 81 21 64
> Kista, = Sweden           &= nbsp;          email:  = loa.andersson@acreo.se
>           &nb= sp;           &nbs= p;            = ;       loa@pi.nu
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/= mailman/listinfo/pwe3
>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/= mailman/listinfo/mpls

------_=_NextPart_001_01C93B59.8955C5E2-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 10:46:06 +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-spc-rsvpte-ext-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081031104501.718B43A6BA6@core3.amsl.com> Date: Fri, 31 Oct 2008 03: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-spc-rsvpte-ext-02.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt Pages : 23 Date : 2008-10-31 We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. See draft "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. Failure conductions and subsequent roll back are also illustrated taking into account that an handover failure must not impact the already established data plane connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-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-pc-spc-rsvpte-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31033037.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 10:17:44 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , Subject: Re: MRN ext. doc Date: Fri, 31 Oct 2008 10:15:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Thanks. Closing on a couple of points... >> It would make sense for section 7 to reference >> draft-ietf-mpls-mpls-and-gmpls-security-framework > > do you have any specific point not covered by this section and covered > by the above ref. The IESG has repeatedly shown itself to be nervous about the security considerations of MPLS and GMPLS networks. Rather than be forced to reproduce a lot of material through a series of exchanges during IESG review and a sequence of updates to the draft at that stage, it seems pragmatic to include a reference to the general analysis of MPLS and GMPLS security. >> === >> We will definitely (well, very probably) be asked if we can show >> traceability back to the requirements. In fact, RFC 5339 >> includes section >> 4.1 that gives traceability from the evaluation back to the >> requirements. >> Section 2 of this document does not quite give the same level of >> traceability such that it is necessary to read most of 5339 >> to ensure that all requirements have been met. > > the current doc. covers the "delta" in terms of mechanism. so, do you > mean that mechanisms not requiring any extensions shall also be > included/described in this document ? Nope. Simply that the I-D should explicitly call out the lacunae identified in RFC 5339. For example, you could say... The following features are identified in [RFC5339] as requiring protocol extensions: 1. Feature to do something. See Section 1.2.3 of [RFC5339] 2. ... >> === >> Section 4 appears to consider only the mapped server model >> (allowing a many to one mapping), but not the multiplexed >> server model. Is it the intention to defer this to Section 5? > > i don't understand the question. Hmm. I'm using ITU terminology. Mapped server has a connection set up in the server layer "on demand" with only the bandwidth required by the client layer connection. Many-to-one mapped server allows that the server connection set up for a previous client layer connection may have "spare" bandwidth that can be allocated ("on demand") to support a further client layer connection. Multiplexed server model causes the "spare" bandwidth to be advertised in the client layer as a link. My question was trying to understand how the required function was split between the two sections 4 and 5. >> === >> Section 5 does not include reference to >> draft-ietf-ccamp-lsp-hierarchy-bis even though this is mentioned >> in RFC 5339. Shouldn't it? >> Actually, there is no mention in section 5 of using RFC 4206 >> procedures to set up FAs to form virtual TE links although that is >> clearly intended in 4206. > > referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206 I don't see any reference to draft-ietf-ccamp-lsp-hierarchy-bis in 5.1 or 5.2. Section 5.1 "relies on extensions to the GMPLS RSVP-TE Call procedure" so is not the same as the 4206 procedure. Section 5.2 is the "Soft FA approach" and although this could be achieved with modifications to the 4206 procedures, it is not the main purpose of the 4206 procedures. Perhaps the point is that *this* I-D is only providing additional functions not already described in other documents. If so, you can cover this whole point with a reminder at the top of section 5... This section describes additional features for the support of virtual TE links. The procedures described here complement those defined in [RFC4206] and [HIER-BIS]. >> === >> The Call-Attributes object C-Num is picked from the 11bbbbbb >> class. Why? >> Surely if any node that processes the Notify message does not >> understand the object, you want the Call to fail. > > this what has been agreed from last meeting. see Lou's preso. Well, it's wrong! :-) It doesn't make sense to use 11bbbbbb. Consider that you are using a Notify message that is targetted. Therefore, the first node to process the Notify message is the intended end point of the call, or a deliberate transit call controller. That means that we require the recipient to be able to process the object. Furthermore, there is nowhere for the message to be forwarded if the object is not understood. The special case of a Notify that is forwarded hop-by-hop does not require that the Call-Attributes object is processed since transit nodes "just forward the Notify message to the target node" without looking at the contents. We should use 0bbbbbbb >> === >> I'm puzzled that the Call described in section 5.1 does not >> indicate to the intended LSP egress in which layer or >> region the soon-to-be-set-up LSP will be required to >> operate. > > because > > - it is the FA setup that indicates to which bearer the virtual > link will be associated not the other way around > > - the virtual association is used by upper-region LSP so the virtual > link itself is an abstraction of the bearer/network (in other terms - > and by definition - one does not create Virtual TE links over Virtual > TE links) > > the only condition which can be verified from the TEDB is that both > ends of the bearer belongs to the same LSP region (symmetry). I meant... Suppose the head and tail of the planned virtual TE link are present in three regions (or layers, don't forget layers). One is the client, and two are potential servers. Shouldn't the call indicate which server the caller wishes/intends to use? >> === >> I don't find section 3.2.1 clear on the co-existence within >> the Link TLV of the IACD sub-TLV and the ISCD sub- >> TLV [RFC4203]. > > i will add a statement IACD does not modify format/messaging and > processing associated to the ISCD. Thanks. Now since there is a an aggregate duplication of information, what happens if the bandwidth cited in the IACD is greater than that in the ISCD? etc. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 Oct 2008 08:40:09 +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: MRN ext. doc Date: Fri, 31 Oct 2008 09:37:05 +0100 Message-ID: <00275A5B436CA441900CB10936742A38014BA1CA@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: MRN ext. doc Thread-Index: Ack66O1Lcar2QjxCSky3c8C+KqTs5QAPqnvQ From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , hi adrian=20 thx for the feedback - here below a couple of hints:=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Friday, October 31, 2008 12:40 AM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: MRN ext. doc >=20 > Hi Dimitri, >=20 > A very quick scan of this I-D raises a few points. >=20 > =3D=3D=3D > Section 2 references [GR-TELINK]. Is this intended to be=20 > draft-ietf-ccamp-mpls-graceful-shutdown-08.txt? > There is nothing in the references section to indicate. yes will add a ref. > =3D=3D=3D > Section 8 needs to be resolved yes already part of the update > =3D=3D=3D > It would make sense for section 7 to reference=20 > draft-ietf-mpls-mpls-and-gmpls-security-framework do you have any specific point not covered by this section and covered by the above ref. > =3D=3D=3D > We will definitely (well, very probably) be asked if we can show=20 > traceability back to the requirements. In fact, RFC 5339=20 > includes section=20 > 4.1 that gives traceability from the evaluation back to the=20 > requirements.=20 > Section 2 of this document does not quite give the same level of=20 > traceability such that it is necessary to read most of 5339=20 > to ensure that=20 > all requirements have been met. the current doc. covers the "delta" in terms of mechanism. so, do you mean that mechanisms not requiring any extensions shall also be included/described in this document ?=20 > =3D=3D=3D > References need updating. idnits should help you. > =3D=3D=3D > Section 4 refers to section 8.2 of RFC 4206. Should be 6.2? yes.=20 > =3D=3D=3D > Section 4 appears to consider only the mapped server model=20 > (allowing a many=20 > to one mapping), but not the multiplexed server model. Is it=20 > the intention=20 > to defer this to Section 5? i don't understand the question.=20 > =3D=3D=3D > Section 5 does not include reference to=20 > draft-ietf-ccamp-lsp-hierarchy-bis=20 > even though this is mentioned in RFC 5339. Shouldn't it? > Actually, there is no mention in section 5 of using RFC 4206=20 > procedures to=20 > set up FAs to form virtual TE links although that is clearly=20 > intended in=20 > 4206. referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206 > =3D=3D=3D > The Call-Attributes object C-Num is picked from the 11bbbbbb=20 > class. Why?=20 > Surely if any node that processes the Notify message does not=20 > understand the=20 > object, you want the Call to fail. this what has been agreed from last meeting. see Lou's preso. > =3D=3D=3D > I'm puzzled that the Call described in section 5.1 does not=20 > indicate to the=20 > intended LSP egress in which layer or region the=20 > soon-to-be-set-up LSP will=20 > be required to operate. because=20 - it is the FA setup that indicates to which bearer the virtual link will be associated not the other way around=20 - the virtual association is used by upper-region LSP so the virtual link itself is an abstraction of the bearer/network (in other terms - and by definition - one does not create Virtual TE links over Virtual TE links) the only condition which can be verified from the TEDB is that both ends of the bearer belongs to the same LSP region (symmetry). > =3D=3D=3D > I don't find section 3.2.1 clear on the co-existence within=20 > the Link TLV of=20 > the IACD sub-TLV and the ISCD sub-TLV [RFC4203]. i will add a statement IACD does not modify format/messaging and processing associated to the ISCD. > =3D=3D=3D > I think it would be valuable to indicate in the Abstract that=20 > this work is=20 > limited to the application of a single TE domain across=20 > multiple regions or=20 > layers. > Furthermore, in the Introduction where this point is raised,=20 > it would be=20 > helpful to explain the meaning of a "single TE domain." There=20 > is a passable=20 > definition in RFC 5212 section 1. TE domain is defined as group of LSRs that enforces a common TE policy.=20 > It would be worth clarifying whether a single TE domain can=20 > be served by=20 > more than one IGP instance. This is hinted at in section 5.7=20 > of RFC 5212. per 5212, we did even not limit it to single AS. for the specific question you ask wrt IGP, in a sense we bind applicability to IGP capability not the other way around. thanks, -d. > =3D=3D=3D >=20 > Thanks, > Adrian >=20 > ----- Original Message -----=20 > From: "PAPADIMITRIOU Dimitri"=20 > > To: > Sent: Monday, October 27, 2008 8:04 AM > Subject: MRN ext. doc >=20 >=20 > folks - >=20 > before asking for LC, we plan an update of this doc. see: >=20 > n-extensio > ns-02.txt> >=20 > please let us know if you see any missing description/holes in this > version (beside its IANA section). >=20 > thx, > -d. >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Oct 2008 23:42:46 +0000 Message-ID: <8748264690F046B189E400061FE9FF7D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , Subject: Re: MRN ext. doc Date: Thu, 30 Oct 2008 23:40:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Dimitri, A very quick scan of this I-D raises a few points. === Section 2 references [GR-TELINK]. Is this intended to be draft-ietf-ccamp-mpls-graceful-shutdown-08.txt? There is nothing in the references section to indicate. === Section 8 needs to be resolved === It would make sense for section 7 to reference draft-ietf-mpls-mpls-and-gmpls-security-framework === We will definitely (well, very probably) be asked if we can show traceability back to the requirements. In fact, RFC 5339 includes section 4.1 that gives traceability from the evaluation back to the requirements. Section 2 of this document does not quite give the same level of traceability such that it is necessary to read most of 5339 to ensure that all requirements have been met. === References need updating. idnits should help you. === Section 4 refers to section 8.2 of RFC 4206. Should be 6.2? === Section 4 appears to consider only the mapped server model (allowing a many to one mapping), but not the multiplexed server model. Is it the intention to defer this to Section 5? === Section 5 does not include reference to draft-ietf-ccamp-lsp-hierarchy-bis even though this is mentioned in RFC 5339. Shouldn't it? Actually, there is no mention in section 5 of using RFC 4206 procedures to set up FAs to form virtual TE links although that is clearly intended in 4206. === The Call-Attributes object C-Num is picked from the 11bbbbbb class. Why? Surely if any node that processes the Notify message does not understand the object, you want the Call to fail. === I'm puzzled that the Call described in section 5.1 does not indicate to the intended LSP egress in which layer or region the soon-to-be-set-up LSP will be required to operate. === I don't find section 3.2.1 clear on the co-existence within the Link TLV of the IACD sub-TLV and the ISCD sub-TLV [RFC4203]. === I think it would be valuable to indicate in the Abstract that this work is limited to the application of a single TE domain across multiple regions or layers. Furthermore, in the Introduction where this point is raised, it would be helpful to explain the meaning of a "single TE domain." There is a passable definition in RFC 5212 section 1. It would be worth clarifying whether a single TE domain can be served by more than one IGP instance. This is hinted at in section 5.7 of RFC 5212. === Thanks, Adrian ----- Original Message ----- From: "PAPADIMITRIOU Dimitri" To: Sent: Monday, October 27, 2008 8:04 AM Subject: MRN ext. doc folks - before asking for LC, we plan an update of this doc. see: please let us know if you see any missing description/holes in this version (beside its IANA section). thx, -d. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Oct 2008 18:58:05 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Protocol Action: 'OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Proposed Standard Message-Id: <20081030185634.61BCC3A6909@core3.amsl.com> Date: Thu, 30 Oct 2008 11:56:34 -0700 (PDT) The IESG has approved the following document: - 'OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering ' as a Proposed Standard 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-ospf-interas-te-extension-06.txt Technical Summary This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. Working Group Summary WG has good consensus. The document was also last called in the OSPF working group (as well as CCAMP) and comments resolved. Document Quality There is at least one implementation of the OSPF v2 extensions. No known implementation (yet) of the OSPF v3 extensions (ie, extensions to support IPv6). Document review by Acee Lindem deserves mention for its care and thoroughness. Personnel Adrian Farrel is the document shepherd. Ross Callon is the responsible AD. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Oct 2008 15:36:33 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Protocol Action: 'ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Proposed Standard Message-Id: <20081030153425.D76283A6A82@core3.amsl.com> Date: Thu, 30 Oct 2008 08:34:25 -0700 (PDT) The IESG has approved the following document: - 'ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering ' as a Proposed Standard 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-isis-interas-te-extension-04.txt Technical Summary This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. Working Group Summary Good consensus reported. The document has had a good level of discussions and review in CCAMP and in the ISIS working group. In particular, it received considerable input from IS-IS experts in its early stages. It was last called in both CCAMP and IS-IS working groups and updated in response to comments. Document Quality There is a known implementation of the extensions, in addition to a known implementation of the very similar OSPF document. There was also good support for the work from other vendors with the same objectives. Document review by the IS-IS working group deserves special mention for its care and thoroughness. Personnel Adrian Farrel is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note Please add the following text to the end of the first paragraph of section 5 (security considerations): (e.g., using the cleartext passwords or Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm which are defined in [ISIS] and [RFC3567bis] separately.)" Please add the following paragraph to the end of section 5 (security considerations): For a discussion of general security considerations for IS-IS see [RFC3567bis]. Please add RFC3567bis to section 8.1 (normative references), this refers to draft-ietf-isis-rfc3567bis (which should be an RFC ahead of this draft -- it is now RFC 5304). Please update Section 6.2 as follows: OLD This document defines the following new sub-TLV types, described in Sections 3.3.1, 3.3.2 and 3.3.3, of top-level TLV 141 (see section 6.1 above) that need to be registered in the ISIS sub-TLV registry for TLV 141, note that these three new sub-TLVs SHOULD NOT appear in TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222): Type Description Length ---- ------------------------------ -------- 23 Remote AS number 4 24 IPv4 Remote ASBR Identifier 4 25 IPv6 Remote ASBR Identifier 16 As described above in Section 3.1, the sub-TLVs which are defined in [ISIS-TE], [ISIS-TE-V3] and other documents for describing the TE properties of an TE link are applicable to describe an inter-AS TE link and MAY be included in the Inter-AS Reachability TLV when adverting inter-AS TE links. And it's possible that some sub-TLVs may be defined for inclusion in both TLV 22 and TLV 141 in the future. It's better if these sub-TLVs have the same registry value no matter where they are included in TLV 22 or TLV 141. The same condition will occur when these sub-TLVs need to be included in TLV 222. So, in order to simplify the registration and reduce the potential code point conflict, this document suggests that TLV 22, TLV 141 and TLV 222 share the same sub-TLV registry. The proposal is that change the current Registry Name from "Sub-TLVs for TLV 22" to "Sub-TLVs for TLV 22, 141 and 222" and add three columns ("May be present on TLV 22","May be present on TLV 141" and "May be present on TLV 222") to the registry for indicating whether a specific sub- TLV may be present on the TLV. NEW This document defines the following new sub-TLV types, described in Sections 3.3.1, 3.3.2 and 3.3.3, of top-level TLV 141 (see section 6.1 above) that need to be registered in the ISIS sub-TLV registry for TLV 141, note that these three new sub-TLVs SHOULD NOT appear in TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222): Type Description ---- ------------------------------ 24 Remote AS number 25 IPv4 Remote ASBR Identifier 26 IPv6 Remote ASBR Identifier As described above in Section 3.1, the sub-TLVs which are defined in [ISIS-TE], [ISIS-TE-V3] and other documents for describing the TE properties of an TE link are applicable to describe an inter-AS TE link and MAY be included in the Inter-AS Reachability TLV when adverting inter-AS TE links. IANA is requested to update the registry currently specified as "Sub-TLVs for TLV 22" to be named "Sub-TLVs for TLVs 22, 141, and 222". Three new columns should be added to the registry to show in which TLVs the sub-TLVs may be present. All sub-TLVs currently defined may be present in all three TLVs, hence the registry (with the definition of the new sub-TLVs defined here) should read as follows. TLV TLV TLV Type Description 22 141 222 Reference ------- ------------------------------------ --- --- --- --------- 0 Unassigned y y y 1 Unassigned y y y 2 Unassigned y y y 3 Administrative group (color) y y y [RFC5305] 4 Link Local/Remote Identifiers y y y [RFC4205][RFC5307] 5 Unassigned y y y 6 IPv4 interface address y y y [RFC5305] 7 Unassigned y y y 8 IPv4 neighbor address y y y [RFC5305] 9 Maximum link bandwidth y y y [RFC5305] 10 Maximum reservable link bandwidth y y y [RFC5305] 11 Unreserved bandwidth y y y [RFC5305] 12 Unassigned y y y 13 Unassigned y y y 14 Unassigned y y y 15 Unassigned y y y 16 Unassigned y y y 17 Unassigned y y y 18 TE Default metric y y y [RFC5305] 19 Link-attributes y y y [RFC5029] 20 Link Protection Type y y y [RFC4205][RFC5307] 21 Interface Switching Capability Desc y y y [RFC4205][RFC5307] 22 Bandwidth Constraints y y y [RFC4124] 23 Unconstrained TE LSP Count (sub-)TLV y y y [RFC-ietf-mpls-number-0-bw-te-lsps-12.txt] 24 Remote AS number n y n [This.I-D] 25 IPv4 Remote ASBR Identifier n y n [This.I-D] 26 IPv6 Remote ASBR Identifier n y n [This.I-D] 27-249 Unassigned 250-254 Reserved for Cisco-specific exts 255 Reserved for future expansion Further sub-TLVs may be defined in the future for inclusion in any of the TLVs 22, 141, or 222. The re-naming of the registry as above ensures that there is no accidental overlap of sub-TLV codepoints. The introduction of the columns within the registry clarify the use of the sub-TLVs. IANA Note Please note substantial IANA update in the RFC editor's note. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 Oct 2008 04:02:53 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-confirm-data-channel-status-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081030040001.C6DF93A6908@core3.amsl.com> Date: Wed, 29 Oct 2008 21: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 : Data Channel Status Confirmation Extensions for the Link Management Protocol Author(s) : D. Li, et al. Filename : draft-ietf-ccamp-confirm-data-channel-status-01.txt Pages : 15 Date : 2008-10-29 This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-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-confirm-data-channel-status-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-29204657.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 21:53:20 +0000 Date: Wed, 29 Oct 2008 21:51:22 +0000 From: "So, Ning" Subject: RE: New draft of the framework and requirements for Composite Transport Group To: ccamp@ops.ietf.org Message-id: <84042721A487BB4C83FC772185400CB707C7498F@ASHEVS010.mcilink.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C93A10.7BD479A9" Content-class: urn:content-classes:message Thread-topic: New draft of the framework and requirements for Composite Transport Group Thread-index: Ack6BXCmfOqsCudJSfyuUtnJ5SiqIwAAhUZfAAHBfvAAAHk+MA== This is a multi-part message in MIME format. ------_=_NextPart_001_01C93A10.7BD479A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, =20 Most of the trouble-shooting mechanisms working today should be able to work across CTG as well. I am sure I have not thought of everything, but I have not seen any problems. Could you please be more specific on the problem and the trouble-shooting method you are thinking here? =20 =20 Ning So Lead Engineer Data Traffic Engineering 972-729-7905 =20 ________________________________ From: Thomas D. Nadeau [mailto:tom.nadeau@bt.com]=20 Sent: Wednesday, October 29, 2008 3:47 PM To: So, Ning; ccamp@ops.ietf.org; Andrew G. (Andy) Malis Subject: Re: New draft of the framework and requirements for Composite Transport Group =20 Have you guys given any thought to the OAM ramifications of your approach? I see no discussion of this in the draft. I ask because extensions were done to LSP ping which took great pains to make work correctly. Have you thought about how to trouble-shoot this mechanism if there are faults? --Tom On 10/29/08 4:32 PM, "So, Ning" wrote: Dear all, =20 We have uploaded the draft of the framework and requirements for Composite Transport Group. =20 http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-framework-req uirement-00.txt =20 Abstract =20 This document states a traffic distribution problem in today's IP/ =20 MPLS network when multiple links are configured between two routers. =20 The document presents a Composite Transport Group framework as the =20 solution for the problems and specifies a set of requirements for =20 Composite Transport Group(CTG). =20 We appreciate your input/comments and look forward to discussing in Minneapolis. =20 Ning So Lead Engineer Data Traffic Engineering 972-729-7905 =20 ------_=_NextPart_001_01C93A10.7BD479A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: New draft of the framework and requirements for Composite = Transport Group

Tom,

 

Most of the trouble-shooting = mechanisms working today should be able to work across CTG as well.  I am sure = I have not thought of everything, but I have not seen any problems.  Could = you please be more specific on the problem and the trouble-shooting method = you are thinking here?    

 

Ning So

Lead Engineer

Data Traffic = Engineering

972-729-7905

 

=

From: = Thomas D. Nadeau [mailto:tom.nadeau@bt.com]
Sent: Wednesday, October = 29, 2008 3:47 PM
To: So, Ning; = ccamp@ops.ietf.org; Andrew G. (Andy) Malis
Subject: Re: New draft of = the framework and requirements for Composite Transport = Group

 


    Have you guys given any thought to the OAM ramifications of your approach? I see no discussion of this in the = draft.  I ask because extensions were done to LSP ping which took =  great pains to make work correctly.  Have you thought about how to = trouble-shoot this mechanism if there are faults?

    --Tom



On 10/29/08 4:32 PM, "So, Ning" <ning.so@verizonbusiness.com> = wrote:

Dear all,
 
We have uploaded the draft of the framework and requirements for = Composite Transport Group.
 
http://www.ietf.org/internet-drafts/draft-so-yong= -mpls-ctg-framework-requirement-00.txt
 
Abstract
 
   This document states a traffic distribution problem in today's IP/
 
   MPLS network when multiple links are configured = between two routers.
 
   The document presents a Composite Transport Group = framework as the
 
   solution for the problems and specifies a set of = requirements for
 
   Composite Transport Group(CTG).
 
We appreciate your input/comments and look forward to discussing in = Minneapolis.

 
Ning So
Lead Engineer
Data Traffic Engineering
972-729-7905

 

------_=_NextPart_001_01C93A10.7BD479A9-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 20:48:18 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 29 Oct 2008 16:47:14 -0400 Subject: Re: New draft of the framework and requirements for Composite Transport Group From: "Thomas D. Nadeau" To: "So, Ning" , , "Andrew G. (Andy) Malis" Message-ID: Thread-Topic: New draft of the framework and requirements for Composite Transport Group Thread-Index: Ack6BXCmfOqsCudJSfyuUtnJ5SiqIwAAhUZf Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3308143634_2905413" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3308143634_2905413 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Have you guys given any thought to the OAM ramifications of your approach? I see no discussion of this in the draft. I ask because extensions were done to LSP ping which took great pains to make work correctly. Have you thought about how to trouble-shoot this mechanism if there are faults? --Tom On 10/29/08 4:32 PM, "So, Ning" wrote: > Dear all, > > We have uploaded the draft of the framework and requirements for Composite > Transport Group. > > http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-framework-requireme > nt-00.txt > > Abstract > > This document states a traffic distribution problem in today's IP/ > > MPLS network when multiple links are configured between two routers. > > The document presents a Composite Transport Group framework as the > > solution for the problems and specifies a set of requirements for > > Composite Transport Group(CTG). > > We appreciate your input/comments and look forward to discussing in > Minneapolis. > > > Ning So > Lead Engineer > Data Traffic Engineering > 972-729-7905 > > > --B_3308143634_2905413 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: New draft of the framework and requirements for Composite Transp= ort Group
    Have you guys given any thought to the OAM ramifica= tions of your approach? I see no discussion of this in the draft.  I as= k because extensions were done to LSP ping which took  great pains to m= ake work correctly.  Have you thought about how to trouble-shoot this m= echanism if there are faults?

    --Tom



On 10/29/08 4:32 PM, "So, Ning" <ning.so@verizonbusiness.com> wrote:

Dear all,
 
We have uploaded the draft of the framework and requirements for Composite = Transport Group.
 
http://www.ietf.org/internet-drafts/draft-so-yong-mpl= s-ctg-framework-requirement-00.txt
 
Abstract
 
   This document states a traffic distribution problem in to= day's IP/
 
   MPLS network when multiple links are configured between t= wo routers.
 
   The document presents a Composite Transport Group framewo= rk as the
 
   solution for the problems and specifies a set of requirem= ents for
 
   Composite Transport Group(CTG).
 
We appreciate your input/comments and look forward to discussing in Minneap= olis.
 
Ning So
Lead Engineer
Data Traffic Engineering
972-729-7905
 

--B_3308143634_2905413-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 20:34:14 +0000 Date: Wed, 29 Oct 2008 20:32:19 +0000 From: "So, Ning" Subject: New draft of the framework and requirements for Composite Transport Group To: ccamp@ops.ietf.org Message-id: <84042721A487BB4C83FC772185400CB707C7498B@ASHEVS010.mcilink.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C93A05.7084F1DB" Content-class: urn:content-classes:message Thread-topic: New draft of the framework and requirements for Composite Transport Group Thread-index: Ack6BXCmfOqsCudJSfyuUtnJ5SiqIw== This is a multi-part message in MIME format. ------_=_NextPart_001_01C93A05.7084F1DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 We have uploaded the draft of the framework and requirements for Composite Transport Group. =20 http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-framework-req uirement-00.txt =20 Abstract =20 This document states a traffic distribution problem in today's IP/ =20 MPLS network when multiple links are configured between two routers. =20 The document presents a Composite Transport Group framework as the =20 solution for the problems and specifies a set of requirements for =20 Composite Transport Group(CTG). =20 We appreciate your input/comments and look forward to discussing in Minneapolis. =20 =20 Ning So Lead Engineer Data Traffic Engineering 972-729-7905 =20 =20 ------_=_NextPart_001_01C93A05.7084F1DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

We have uploaded = the draft of the framework and requirements for Composite Transport = Group.

 

http://www.ietf.org/internet-drafts/draft-so-yong-mpls-ctg-frame= work-requirement-00.txt

 

Abstract

 

   This = document states a traffic distribution problem in today's IP/

 

   MPLS = network when multiple links are configured between two = routers.

 

   The = document presents a Composite Transport Group framework as the

 

   = solution for the problems and specifies a set of requirements for

 

   = Composite Transport Group(CTG).

 

We appreciate your input/comments and look forward to discussing in Minneapolis.<= /p>

 

 

Ning So

Lead Engineer

Data Traffic Engineering

972-729-7905

 

 

------_=_NextPart_001_01C93A05.7084F1DB-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 20:00:54 +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-ason-routing-ospf-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081029200004.BD7213A685A@core3.amsl.com> Date: Wed, 29 Oct 2008 13:00:04 -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 : OSPFv2 Routing Protocols Extensions for ASON Routing Author(s) : D. Papadimitriou, I. Property Filename : draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt Pages : 27 Date : 2008-10-29 The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines to the OSPFv2 Link State Routing Protocol to meet the routing requirements for routing in an ASON. D.Papadimitriou et al. - Expires April 2009 [page 1] draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt October 2008 Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-06.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-ason-routing-ospf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-29124635.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 19:49:56 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Wed, 29 Oct 2008 19:47:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit This email starts a two week working group last call on "GMPLS Ethernet Label Switching Architecture and Framework" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-03.txt The I-D is marked as Informational. Please send your comments to the list by 12 noon GMT Friday 14th November. Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 17:31:47 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=bQv7GusXQAl1Eaj2ykrwVGf0zWTuxzGkB3B9LZDN1R9GLafSyLpDfLGdXv+nqxxpl17sTi52e0SnmQC9T28ULEC9S+woTmHWjHqZla9eHjPP6JMMXe/WVQsd1yabfxAr; Date: Wed, 29 Oct 2008 13:29:49 -0400 To: "Zafar Ali (zali)" From: Lou Berger Subject: RE: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Cc: "Lou Berger" ,"Adrian Farrel" , ,,, "Anca Zamfir (ancaz)" , "Newton, Jonathan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Zafar, In short, you don't need new error codes to support the upstream identification of type of reroute being indicated (node, interface, component, label). This can be determined based on the ERROR_SPEC object and included TLVs. This is already covered in the reroute draft. I thought the text at the end of 2.1 of the reroute draft was sufficiently clear to indicate how one would do this with the existing error codes. I guess some examples for each of the cases will make this more apparent. looks like there are still open issues in the draft(s)... Lou At 12:34 PM 10/29/2008, Zafar Ali (zali) wrote: >Hi Lou- > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > Sent: Wednesday, October 29, 2008 11:56 AM > > To: Zafar Ali (zali) > > Cc: Lou Berger; Adrian Farrel; ccamp@ops.ietf.org; > > mpls@ietf.org; jpv@cisco.com; Anca Zamfir (ancaz); Newton, Jonathan > > Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown > > > > Zafar, > > > > Why does the document define new error codes (and why 4)? Is > > it that the reroute document isn't sufficient clear on how to > > indicated each of the 4? Is it some other reason? > > > >This is because headend may be able to compute alternate route >("reroute" action) for mb4b differently, depending on the resource under >graceful shutdown, as detailed in the document. Hence one code is define >for TE node, TE link, component link of a bundled TE link, and label >resource, each. > >Thanks > >Regards... Zafar > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 16:36:17 +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: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Wed, 29 Oct 2008 12:34:47 -0400 Message-ID: Thread-Topic: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbA From: "Zafar Ali (zali)" To: "Lou Berger" Cc: "Adrian Farrel" , , , , "Anca Zamfir (ancaz)" , "Newton, Jonathan" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=972; t=1225298107; x=1226162107; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20RE=3A=20Updates=20to=20draft-ietf-ccamp-mpls-gr aceful-shutdown |Sender:=20; bh=ppTpGEZ3QoX1+7NM1oqTa40cus0UgYf/sATwnuIRL5c=; b=eSCCiP3gLox9mwtGwVq3q7b21frK0PoMP74yvWFfF1vuo1HQFUuuyRyLH9 77zRvpTiaR8ysLoArfFqPuQ0YutWtMo9FNrFN1Pry8OGjmyw/yLFLsgGJD1x RkwyMVU/sC; Authentication-Results: sj-dkim-3; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Hi Lou- =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, October 29, 2008 11:56 AM > To: Zafar Ali (zali) > Cc: Lou Berger; Adrian Farrel; ccamp@ops.ietf.org;=20 > mpls@ietf.org; jpv@cisco.com; Anca Zamfir (ancaz); Newton, Jonathan > Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown >=20 > Zafar, >=20 > Why does the document define new error codes (and why 4)? Is=20 > it that the reroute document isn't sufficient clear on how to=20 > indicated each of the 4? Is it some other reason? >=20 This is because headend may be able to compute alternate route ("reroute" action) for mb4b differently, depending on the resource under graceful shutdown, as detailed in the document. Hence one code is define for TE node, TE link, component link of a bundled TE link, and label resource, each.=20 Thanks Regards... Zafar=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 15:57:56 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=YeYob4qHtee2ukmqdDvuS76a7fonCCUnlPfU3SxKfd9FkSt7k7EyZU54KS//AV7wgB+DVEkS6mvzKbn8qmxhBMoBcvjc8d/BuqwQ+ILJqSlcNpUpoHbmzpDGnEY6R1vR; Date: Wed, 29 Oct 2008 11:56:18 -0400 To: "Zafar Ali (zali)" From: Lou Berger Subject: Re: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Cc: "Lou Berger" ,"Adrian Farrel" , ,,, "Anca Zamfir (ancaz)" , "Newton, Jonathan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Zafar, Why does the document define new error codes (and why 4)? Is it that the reroute document isn't sufficient clear on how to indicated each of the 4? Is it some other reason? Thanks, Lou At 11:36 AM 10/29/2008, Zafar Ali (zali) wrote: >Hi Lou, Adrian, Deborah, et al- > >We have modified the draft-ietf-ccamp-mpls-graceful-shutdown to >reflect changes proposed in "draft-ietf-mpls-gmpls-lsp-reroute". >This was a comment from Lou during the last call of this draft. This >was the only outstanding comment from the LC. > >In the light of the above, can you please take a quick look at >draft-ietf-ccamp-mpls-graceful-shutdown-08.txt to make sure that the >changes are correctly in synch with the >draft-ietf-mpls-gmpls-lsp-reroute work. > >Thanks for your input. > >Regards... Zafar Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 15:38:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C939DC.20E4766F" Subject: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Wed, 29 Oct 2008 11:36:32 -0400 Message-ID: Thread-Topic: Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53B6q/yDjWG9SR6aYcY8pbCH7Cw== From: "Zafar Ali (zali)" To: "Lou Berger" Cc: "Adrian Farrel" , , , , "Anca Zamfir (ancaz)" , "Newton, Jonathan" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2153; t=1225294636; x=1226158636; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20Updates=20to=20draft-ietf-ccamp-mpls-graceful-s hutdown |Sender:=20 |To:=20=22Lou=20Berger=22=20; bh=VpMzwXBbUpvFyawbxtsGUvOe0/blVvr7ge7PGZr/nWQ=; b=dvkSajH3hEhGr/aHup9lqzBqSMfBNk5kASXkTXERoKZR0xhyeJqMKqIUl8 XWODIm2mQ8ltAZnQiw9P7WrkLJhKrhVhJ2C+JuLHCDz1Em/lz+qzqeNYn6bR YKyS5GUwpr; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C939DC.20E4766F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou, Adrian, Deborah, et al-=20 We have modified the draft-ietf-ccamp-mpls-graceful-shutdown to reflect changes proposed in "draft-ietf-mpls-gmpls-lsp-reroute". This was a comment from Lou during the last call of this draft. This was the only outstanding comment from the LC.=20 In the light of the above, can you please take a quick look at draft-ietf-ccamp-mpls-graceful-shutdown-08.txt to make sure that the changes are correctly in synch with the draft-ietf-mpls-gmpls-lsp-reroute work.=20 Thanks for your input.=20 Regards... Zafar=20 ------_=_NextPart_001_01C939DC.20E4766F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updates to draft-ietf-ccamp-mpls-graceful-shutdown

Hi Lou, Adrian, = Deborah, et al-

We have modified the = draft-ietf-ccamp-mpls-graceful-shutdown to reflect changes proposed in = "draft-ietf-mpls-gmpls-lsp-reroute". This was a comment from = Lou during the last call of this draft. This was the only outstanding = comment from the LC.

In the light of the = above, can you please take a quick look at = draft-ietf-ccamp-mpls-graceful-shutdown-08.txt to make sure that the = changes are correctly in synch with the = draft-ietf-mpls-gmpls-lsp-reroute work.

Thanks for your = input.

Regards... = Zafar=20

------_=_NextPart_001_01C939DC.20E4766F-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 15:01:32 +0000 Message-ID: <6C772407ED48420A961F4FC314886249@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Status of draft-ietf-ccamp-gmpls-g-694-lambda-labels ? Date: Wed, 29 Oct 2008 15:00:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I know that there was some discussion about changes needed to this I-D, but everything seems to have gone quiet. The last comments on the mailing list are dated just after the current version was published, and I think that there were a few small points raised in Dublin. I think we should try to close off this piece of work as soon as possible. Could the authors and editor make a desperate scramble to get a new version out in time for Minneapolis so that we can declare success and move on? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 14:47:58 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081029144501.5B3E43A6D27@core3.amsl.com> Date: Wed, 29 Oct 2008 07: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 : Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-08.txt Pages : 11 Date : 2008-10-29 MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. Ali et al. Expires April 2009 [page 1] draft-ietf-ccamp-mpls-graceful-shutdown-08.txt A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-08.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-mpls-graceful-shutdown-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-29073434.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 Oct 2008 00:00:31 +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] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Wed, 29 Oct 2008 05:27:51 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965020E933C@INEXC1U01.in.lucent.com> Thread-Topic: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Thread-Index: Ack45bUGrlNTVozhT3OOzOfxULkNngAc0CAQ From: "Dutta, Pranjal K \(Pranjal\)" To: "Loa Andersson" , , "pwe3" , , "ccamp" Support. Thanks, Pranjal=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, October 28, 2008 3:12 AM To: mpls@ietf.org; pwe3; ahtmpls@itu.int; ccamp Subject: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Working group(s), this is to initiate a two week poll to see if draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a mpls working group document. The current draft is a merge of to earlier draft one that defined the GAL and another that specified the generic associated channel. Please send your responses to the mpls working group mailing list (needs a bit of discipline, "replay all" won't do the trick ;) . Please respond on Tuesday Oct 11 the latest. /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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Oct 2008 20:30:49 +0000 Message-ID: <2190D314F17643408E235459D4268B44@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Greg Bernstein" , Subject: Re: CCAMP times in Minneapolis... Date: Tue, 28 Oct 2008 20:28:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi Greg, As far as we know these sessions are secure. The "two" sessions on Wednesday morning equate to a usual 2.5 hour session. We would not propose to break for 15 minutes in the middle. Adrian ----- Original Message ----- From: "Greg Bernstein" To: Sent: Monday, October 27, 2008 6:04 PM Subject: CCAMP times in Minneapolis... > Hi working group chairs, from the IETF meeting agenda it looks like there > are three meeting times for CCAMP: > Monday: 1740-1930 Afternoon Session III > Wednesday: 0900-1015 Morning Session I > Wednesday: 1030-1130 Morning Session II > > Are these fairly solid? Not that I don't like Minneapolis... > > Regards > > Greg > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Oct 2008 18:37:05 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Loa Andersson" , "ccamp" Cc: , "pwe3" , Subject: Re: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Tue, 28 Oct 2008 18:33:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Support ----- Original Message ----- From: "Loa Andersson" To: ; "pwe3" ; ; "ccamp" Sent: Tuesday, October 28, 2008 10:12 AM Subject: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc > Working group(s), > > this is to initiate a two week poll to see if > draft-bocci-mpls-tp-gach-gal-00.txt is in shape to > become a mpls working group document. > > The current draft is a merge of to earlier draft > one that defined the GAL and another that specified > the generic associated channel. > > Please send your responses to the mpls working group > mailing list (needs a bit of discipline, "replay all" > won't do the trick ;) . > > Please respond on Tuesday Oct 11 the latest. > > /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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Oct 2008 16:45:52 +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: [mpls] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Tue, 28 Oct 2008 11:43:01 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04C95204@USDALSMBS03.ad3.ad.alcatel.com> Thread-Topic: [mpls] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Thread-Index: Ack45byfagYrwvvLT9mCMeJee3MqKwANnugw From: "AISSAOUI Mustapha" To: "Loa Andersson" , , "pwe3" , , "ccamp" support. Mustapha.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Tuesday, October 28, 2008 6:12 AM > To: mpls@ietf.org; pwe3; ahtmpls@itu.int; ccamp > Subject: [mpls] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc >=20 > Working group(s), >=20 > this is to initiate a two week poll to see if=20 > draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a=20 > mpls working group document. >=20 > The current draft is a merge of to earlier draft one that=20 > defined the GAL and another that specified the generic=20 > associated channel. >=20 > Please send your responses to the mpls working group mailing=20 > list (needs a bit of discipline, "replay all" > won't do the trick ;) . >=20 > Please respond on Tuesday Oct 11 the latest. >=20 > /Loa >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Oct 2008 13:41:40 +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] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Date: Tue, 28 Oct 2008 14:38:30 +0100 Message-ID: <43284B5A95E36B4AB4A91EBA4E0FC31EE6B78B@DEMUEXC030.nsn-intra.net> Thread-Topic: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Thread-Index: Ack45a9i7kRm6Nr9R/u0ZP5cd7068QAHK5Iw From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , "pwe3" , , "ccamp" I support. Nurit -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Tuesday, October 28, 2008 12:12 To: mpls@ietf.org; pwe3; ahtmpls@itu.int; ccamp Subject: [PWE3] draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Working group(s), this is to initiate a two week poll to see if draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a mpls working group document. The current draft is a merge of to earlier draft one that defined the GAL and another that specified the generic associated channel. Please send your responses to the mpls working group mailing list (needs a bit of discipline, "replay all" won't do the trick ;) . Please respond on Tuesday Oct 11 the latest. /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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 Oct 2008 10:14:40 +0000 Message-ID: <4906E57E.4050105@pi.nu> Date: Tue, 28 Oct 2008 11:12:14 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3 , "ahtmpls@itu.int" , ccamp Subject: draft-bocci-mpls-tp-gach-gal-00.txt for mpls wg doc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Working group(s), this is to initiate a two week poll to see if draft-bocci-mpls-tp-gach-gal-00.txt is in shape to become a mpls working group document. The current draft is a merge of to earlier draft one that defined the GAL and another that specified the generic associated channel. Please send your responses to the mpls working group mailing list (needs a bit of discipline, "replay all" won't do the trick ;) . Please respond on Tuesday Oct 11 the latest. /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: Tue, 28 Oct 2008 05:17:47 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081028051501.84EDF3A68E7@core3.amsl.com> Date: Mon, 27 Oct 2008 22: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 : Category: Informational Expires: April 27, 2009 October 28, 2008 Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-07.txt Pages : 11 Date : 2008-10-27 MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-07.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-mpls-graceful-shutdown-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27220717.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Oct 2008 18:06:52 +0000 Message-ID: <490602C4.5000403@grotto-networking.com> Date: Mon, 27 Oct 2008 11:04:52 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: CCAMP times in Minneapolis... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi working group chairs, from the IETF meeting agenda it looks like there are three meeting times for CCAMP: Monday: 1740-1930 Afternoon Session III Wednesday: 0900-1015 Morning Session I Wednesday: 1030-1130 Morning Session II Are these fairly solid? Not that I don't like Minneapolis... Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Oct 2008 12:47:48 +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-ethernet-arch-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027124502.0AC823A6A4E@core3.amsl.com> Date: Mon, 27 Oct 2008 05: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 : GMPLS Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Pages : 20 Date : 2008-10-27 There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as SONET/SDH TDM and ATM. This document defines an architecture and framework for a GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions.Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-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-gmpls-ethernet-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27054310.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 Oct 2008 08:07:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: MRN ext. doc Date: Mon, 27 Oct 2008 09:04:51 +0100 Message-ID: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: MRN ext. doc Thread-Index: Ack4CrAqo5CZmc7IQr24kAGxU45t6w== From: "PAPADIMITRIOU Dimitri" To: folks -=20 before asking for LC, we plan an update of this doc. see:=20 please let us know if you see any missing description/holes in this version (beside its IANA section). thx, -d. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 24 Oct 2008 16:10:08 +0000 Message-ID: <002901c935f2$92f928d0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: A BNF specification for RSVP-GMPLS and LMP Date: Fri, 24 Oct 2008 17:05:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, This draft provides a specification of the BNF we already use in RSVP-TE and LMP and makes it available for use in future protocol extensions. I intend asking that this draft progress in the standards process relatively soon. Please review and comment as soon as possible. Thanks, Adrian ----- Original Message ----- From: To: Sent: Friday, October 24, 2008 5:00 PM Subject: I-D Action:draft-farrel-rtg-common-bnf-06.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Reduced Backus-Naur Form (RBNF) A Syntax Used in Various > Protocol Specifications > Author(s) : A. Farrel > Filename : draft-farrel-rtg-common-bnf-06.txt > Pages : 12 > Date : 2008-10-24 > > Several protocols have been specified using a common variant of the > Backus-Naur Form (BNF) of representing message syntax. However, there > is no formal definition of this version of BNF. > > There is value in using the same variant of BNF for the set of > protocols that are commonly used together. This reduces confusion and > simplifies implementation. > > Updating existing documents to use some other variant of BNF that is > already formally documented would be a substantial piece of work. > > This document provides a formal definition of the variant of BNF that > has been used (that we call Reduced BNF), and makes it available for > use by new protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-06.txt Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 Oct 2008 23:41:04 +0000 To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-ccamp-asymm-bw-bidir-lsps (GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)) to Experimental RFC Reply-to: ietf@ietf.org CC: Message-Id: <20081023233717.7A1D83A6A8F@core3.amsl.com> Date: Thu, 23 Oct 2008 16:37:17 -0700 (PDT) The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17127&rfc_flag=0 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 Oct 2008 15:43:19 +0000 Message-ID: <48FDF81E.3060802@grotto-networking.com> Date: Tue, 21 Oct 2008 08:41:18 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Call for agenda slot requests Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, here's what I know on the WSON front (that doesn't mean that I'll present all this stuff ;-)). Working group documents: (a) Update on the WSON Framework document - Pierre (Alcatel) and Dirk (Cisco) are helping to get this better organized and add application scenarios. I'd probably present - 5 minutes or less (b) Update on the WSON RWA info model - 5 minutes or less -- Not yet working group documents: (c) Update on RWA info model Encoding - 5 minutes or less. (d) Update on WSON signaling -- Some new work/applications extensions we'd like to go over (5 minutes). -- New work (impairment related, these will probably motivate discussion) -- (e) WSON Impairment Framework draft -- This is new work where we look at how the control plane and optical impairments work together and what could fall within the CCAMP (and PCE) charters. (f) WSON Impairment Validation Information Model -- Here we take a first attempt at taking an ITU-T network element centric impairment model and adapting it for use in the control plane. Regards Greg Adrian Farrel wrote: > Hi, > > Please let us know if you would like some time on the CCAMP agenda in > Minneapolis. > > Thanks, > Adrian and Deborah > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 Oct 2008 03:02:05 +0000 Message-ID: <02f801c93328$e43a3c60$84996d26@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Call for agenda slot requests Date: Tue, 21 Oct 2008 03:58:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Please let us know if you would like some time on the CCAMP agenda in Minneapolis. Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 Oct 2008 22: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-lsp-hierarchy-bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081017220001.3979A3A6AFE@core3.amsl.com> Date: Fri, 17 Oct 2008 15: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 : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, A. Farrel, R. Rabbat, A. Ayyangar, Z. Ali Filename : draft-ietf-ccamp-lsp-hierarchy-bis-05.txt Pages : 28 Date : 2008-10-17 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-05.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-lsp-hierarchy-bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-17144849.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 Oct 2008 21:48:07 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-lsp-hierarchy-bis-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081015214501.AD55D3A6A76@core3.amsl.com> Date: Wed, 15 Oct 2008 14: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 : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-04.txt Pages : 28 Date : 2008-10-15 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle.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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-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-lsp-hierarchy-bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-15143443.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 Oct 2008 12:47:03 +0000 Message-ID: <002801c92d2d$17896bb0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison from the ITU "WSON work in Q12/15" Date: Mon, 13 Oct 2008 13:13:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have received a liaison from the Interregnum Meeting of Questions 12 and 14 of Study Group 15 of the ITU-T. The text of the liaison is as follows... > Thank you for your liaison statement of September 6, 2008 to Q3/15 > regarding the OTN work plan advising us of your work on Wavelength > Switched Optical Networks (WSON). > > Q.12/15 has initiated work on developing a network model for WSON, > we will be working in cooperation with Q6/15 to include optical > impairments > in this model. One intended output of this work is a model that can be > used > for path computation in the presence of both optical impairments and > blocking > switches. We note that the aspects related to optical impairments are > quite > challenging and we are engaging the appropriate experts. In view of this > we > would encourage you to continue your focus on networks in which > impairments > can be neglected and only wavelength assignment needs to be considered. > > We noted that you are considering the use of a matrix to represent the > blocking > characteristics of an asymmetrical switch (e.g. ROADM). We are > considering > the use of a bipartite graph since it appears to be suitable for path > computation. > > We will review the internet drafts that you reference and would be obliged > if > you kept us informed of your progress on work in this area. As with all incoming and outgoing communications, you can find this liaison through the alternative CCAMP pages at www.olddog.co.uk/ccamp.htm Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 Oct 2008 12:15:38 +0000 Message-ID: <002701c92d2d$173f9170$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison Received from ITU "GMPLS signaling for VCAT/LCAS (09/2008)" Date: Mon, 13 Oct 2008 13:10:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have received a liaison from the Interregnum Meeting of Questions 12 and 14 of Study Group 15 of the ITU-T. The text of the liaison is as follows... > Thank you for your liaison statement on GMPLS control of VCAT/LCAS dated > September 5, 2008. We also thank Mr. Farrel for presenting the liaison > statement at our Beijing Interregnum meeting. > > At the moment we don't have comment on the -05 version of the GMPLS > VCAT/LCAS I-D (draft-ietf-ccamp-gmpls-vcat-lcas). We are looking > forward to text in future version of the I-D to clarify, as indicated in > your > response, that there are different name (or identifier) spaces even though > they may all use the same IP address format. As with all incoming and outgoing communications, you can find this liaison through the alternative CCAMP pages at www.olddog.co.uk/ccamp.htm Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 04 Oct 2008 18:58:57 +0000 Message-ID: <043d01c92652$fdcdb360$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: RFC 5305 on IS-IS Extensions for Traffic Engineering Date: Sat, 4 Oct 2008 19:50:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi CCAMP, Be aware... > A new Request for Comments is now available in online RFC libraries. > RFC 5305 > Title: IS-IS Extensions for Traffic Engineering > URL: http://www.rfc-editor.org/rfc/rfc5305.txt This obsoletes RFC 3784 but the only change is to move the work onto the standards track. Adrian