From owner-ccamp@ops.ietf.org Sat Nov 1 14:07:04 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 8AA363A6A84 for ; Sat, 1 Nov 2008 14:07:04 -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 ZZy2yBaehb8o for ; Sat, 1 Nov 2008 14:07:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C1F43A69F9 for ; Sat, 1 Nov 2008 14:07:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwNa1-000A29-40 for ccamp-data@psg.com; Sat, 01 Nov 2008 21:00:21 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwNZh-000A0b-Ku for ccamp@ops.ietf.org; Sat, 01 Nov 2008 21:00:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 7BAB13A6AC2; Sat, 1 Nov 2008 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081101210001.7BAB13A6AC2@core3.amsl.com> Date: Sat, 1 Nov 2008 14: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 : Ethernet Traffic Parameters Author(s) : D. Papadimitriou, I. Property Filename : draft-ietf-ccamp-ethernet-traffic-parameters-06.txt Pages : 13 Date : 2008-11-1 This document describes the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-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-ethernet-traffic-parameters-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-1135317.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Sat Nov 1 14: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 27BE93A67E4 for ; Sat, 1 Nov 2008 14:07:10 -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 psUF7rxOsez4 for ; Sat, 1 Nov 2008 14:07:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 218093A67A5 for ; Sat, 1 Nov 2008 14:07:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwNZq-000A1V-C3 for ccamp-data@psg.com; Sat, 01 Nov 2008 21: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 1KwNZh-000A0a-Kv for ccamp@ops.ietf.org; Sat, 01 Nov 2008 21:00:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 782763A6AB3; Sat, 1 Nov 2008 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-path-key-ero-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081101210001.782763A6AB3@core3.amsl.com> Date: Sat, 1 Nov 2008 14: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 : RSVP Extensions for Path Key Support Author(s) : R. Bradford, J. Vasseur, A. Farrel Filename : draft-ietf-ccamp-path-key-ero-02.txt Pages : 14 Date : 2008-11-1 The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation. This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-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-path-key-ero-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-1134915.I-D@ietf.org> --NextPart-- From n21102008@gmail.com Sat Nov 1 23:27:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B8B3A6873 for ; Sat, 1 Nov 2008 23:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW87zylwsQbl for ; Sat, 1 Nov 2008 23:27:15 -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 315D53A6861 for ; Sat, 1 Nov 2008 23:27:15 -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 <0K9P00L1J0KWXDH0@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Sun, 02 Nov 2008 03:26:56 -0300 (ART) Date: Sun, 02 Nov 2008 03:27:46 -0300 From: "n21102008@gmail.com" Subject: NOTEBOOKS DELL, TOSHIBA y HP SOLO POR HOY To: notebooks por hoy Message-id: <385-22008110262746243@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 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 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 Sun Nov 2 09:30:20 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 D953C3A6957 for ; Sun, 2 Nov 2008 09:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=-0.322, 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 e9w-4wXbnrH6 for ; Sun, 2 Nov 2008 09:30:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E2723A67D0 for ; Sun, 2 Nov 2008 09:30:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kwgg0-000Pwo-8S for ccamp-data@psg.com; Sun, 02 Nov 2008 17:23:48 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kwgfo-000Puz-6D for ccamp@ops.ietf.org; Sun, 02 Nov 2008 17:23:43 +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 mA2HNSVm017046; Sun, 2 Nov 2008 17:23:31 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 mA2HNSOB017037; Sun, 2 Nov 2008 17:23:28 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> <00275A5B436CA441900CB10936742A38014BA4AF@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: MRN ext. doc Date: Sun, 2 Nov 2008 17:23:23 -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, >>>> === >>>> 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. ... > > ok - you would like a ref. to 5339. Yes. But not just a simple ref to the doc, but a ref to each of the unanswered requirements in 5339 >>>> === >>>> 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. > > can u please use the ietf terminology at least to make the point > understandable to me (excuse my ignorance). what is a mapped > server ? OK. Well, I did try to explain in my previous response. In the mapped server model, a connection in used in the server layer/region in response to a specific demand for end-to-end connectivity in the client layer/region. In most cases, the server connection is created on-demand when the client connection request reaches the layer boundary. The client connection is "mapped" to the server connection using the adaptation function at the boundary node to provide continuous end-to-end connectivity. The server connection is not made into a link in the client layer/region because its purpose is only to server the current client connection. When the client connection is torn down, the server connection will normally be torn down as well. The many-to-one mapped server case is initiated in the same way, but it may be that it is actually possible to map more than one client connection to the server connection (effectively there is multiplexing in the adaptation function). However, since the server connection is not advertised as a link in the client layer/region, the second client connection to be requested behaves exactly the same except that the border node can (before setting up a new on-demand server connection) note that there is available capacity on an existing server connection and use that. I suppose that the mapped server cases equate to the creation of a data link that is not advertised (i.e. remains as a local client layer/region link across the server layer/region). The case where a TE link is created and advertised equates to the ITU's Multiplexed Server model. >>>> 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. > > 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. I spoke to Lou. He had suggested 11bbbbbb because he thought the object might end up on a Path message. However, we don't think this would actually be the case because the call request message is a Notify. So he is more relaxed about this changing to 0bbbbbbb >> 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? > > 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 I agree completely. And that was my point. The call is a negotiation between end points about what connection will be set up, what adaptions will be applied, and what TE link will be created. This effectively requires the call request to state the set of potential adaptations, and the call response to identify the subset of acceptable adaptations. The connection can then be signaled in the correct switching type, and the resulting LSP can be associated to the TE link. >>>> === >>>> 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 an aggregate duplication of information > > where do you see the "duplication" of information b/w IACD and ISCD ? Well, in the ISCD I see a list of bandwidths available per priority. In the IACD I see a list of bandwidths available per priority. Clearly there is some relationship between these numbers because they refer to the same advertised link. I don't suppose that the sum of the priority 1 bandwidths for all IACDs is supposed to equal the advertised priority 1 bandwidth from the ISCD. But if the priority 1 bandwidths for one IACD was larger than that for the ISCD it would be strange (meaningless?). There is not a direct duplication of information, but there is some overlap of information and I am asking how it is resolved. A From owner-ccamp@ops.ietf.org Sun Nov 2 10:31:37 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CEC3A67D0 for ; Sun, 2 Nov 2008 10:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.471 X-Spam-Level: X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=1.169, 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 DZeo4ZHxuh-H for ; Sun, 2 Nov 2008 10:31:36 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0605F3A67AB for ; Sun, 2 Nov 2008 10:31:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwhdZ-0006e8-0H for ccamp-data@psg.com; Sun, 02 Nov 2008 18:25:21 +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 1KwhdG-0006c4-QM for ccamp@ops.ietf.org; Sun, 02 Nov 2008 18:25:14 +0000 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mA2IOxAC012268; Sun, 2 Nov 2008 19:25:00 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 2 Nov 2008 19:24:59 +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: Sun, 2 Nov 2008 19:24:05 +0100 Message-ID: <00275A5B436CA441900CB10936742A38014BA566@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MRN ext. doc Thread-Index: Ack9D7yCOPB7Oj16RRmWxD55Lc9zfgAAXFgg References: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> <8748264690F046B189E400061FE9FF7D@your029b8cecfe> <00275A5B436CA441900CB10936742A38014BA1CA@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38014BA4AF@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 02 Nov 2008 18:24:59.0970 (UTC) FILETIME=[50BAD220:01C93D18] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: =20 Hi adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Sunday, November 02, 2008 6:23 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: MRN ext. doc >=20 > Hi Dimitri, >=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. > >>> 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. ... > > > > ok - you would like a ref. to 5339. >=20 > Yes. But not just a simple ref to the doc, but a ref to each of the=20 > unanswered requirements in 5339 this is what i meant. > >>>> =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. > >> > >> 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. > > > > can u please use the ietf terminology at least to make the point > > understandable to me (excuse my ignorance). what is a mapped > > server ? >=20 > OK. Well, I did try to explain in my previous response. >=20 > In the mapped server model, a connection in used in the=20 > server layer/region=20 > in response to a specific demand for end-to-end connectivity=20 > in the client=20 > layer/region. In most cases, the server connection is created=20 > on-demand when=20 > the client connection request reaches the layer boundary. The client=20 > connection is "mapped" to the server connection using the adaptation=20 > function at the boundary node to provide continuous=20 > end-to-end connectivity.=20 > The server connection is not made into a link in the client=20 > layer/region=20 > because its purpose is only to server the current client=20 > connection. When=20 > the client connection is torn down, the server connection=20 > will normally be=20 > torn down as well. >=20 > The many-to-one mapped server case is initiated in the same=20 > way, but it may=20 > be that it is actually possible to map more than one client=20 > connection to=20 > the server connection (effectively there is multiplexing in=20 > the adaptation=20 > function). However, since the server connection is not=20 > advertised as a link=20 > in the client layer/region, the second client connection to=20 > be requested=20 > behaves exactly the same except that the border node can=20 > (before setting up=20 > a new on-demand server connection) note that there is=20 > available capacity on=20 > an existing server connection and use that. >=20 > I suppose that the mapped server cases equate to the creation=20 > of a data link=20 > that is not advertised (i.e. remains as a local client=20 > layer/region link=20 > across the server layer/region). The case where a TE link is=20 > created and=20 > advertised equates to the ITU's Multiplexed Server model. ok, i think i barely understood where you are heading at. now what is the issue with the doc. ? honnestly, i do not catch the point you are trying to make: section 4 addresses purely signaling procedure issue (complements existing FA triggering/selection rules) and section 5 a well-known TE problem that is how to attract traffic when no bearer is setup (it is a particular case of the generic unknown adjcacency problem). > >>>> 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. > > > > not sure. at the end the question is an attribute object class a > > criteria for which rejection is expected. going one step=20 > 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=20 > 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=20 > way around. >=20 > I spoke to Lou. > He had suggested 11bbbbbb because he thought the object might=20 > end up on a=20 > Path message. However, we don't think this would actually be the case=20 > because the call request message is a Notify. > So he is more relaxed about this changing to 0bbbbbbb are call attributes mandatorily associated to calls (and which case one could simply mandate support of the related attribute) and their messaging/processing a must have feature of the protocol ? ... just to be clear 0bbbbbbb does not solve the former. > >> 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 >=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 > >>> 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=20 > 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? > > > > assume a base virtual TE link [PSC,PSC] and the two link=20 > sequence that > > can be followed by the FA-LSP are either=20 > [PSC,LSC]..[LSC,LSC]..[LSC,PSC] > > or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association=20 > between the TE > > link and LSP that determines to which FA that TE link is=20 > now related to >=20 > I agree completely. > And that was my point. > The call is a negotiation between end points about what=20 > connection will be=20 > set up, what adaptions will be applied, and what TE link will=20 > be created.=20 > This effectively requires the call request to state the set=20 > of potential=20 > adaptations, and the call response to identify the subset of=20 > acceptable=20 > adaptations. The connection can then be signaled in the=20 > correct switching=20 > type, and the resulting LSP can be associated to the TE link. per 4974, the LINK_CAPABILITY object can be used for this purpose with subobject Type 65.=20 i did not mention it for two reasons a) it is implicit in the context (a Virtual Link by definition addresses the lowest SC value) and b) part of the procedure referenced by this doc. > >>>> =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. > >> > >> Thanks. > >> > >> Now since there is an aggregate duplication of information > > > > where do you see the "duplication" of information b/w IACD=20 > and ISCD ? >=20 > Well, in the ISCD I see a list of bandwidths available per priority. > In the IACD I see a list of bandwidths available per priority. >=20 > Clearly there is some relationship between these numbers=20 > because they refer=20 > to the same advertised link. >=20 > I don't suppose that the sum of the priority 1 bandwidths for=20 > all IACDs is=20 > supposed to equal the advertised priority 1 bandwidth from=20 > the ISCD. But if=20 > the priority 1 bandwidths for one IACD was larger than that=20 > for the ISCD it=20 > would be strange (meaningless?). >=20 > There is not a direct duplication of information, but there=20 > is some overlap=20 > of information and I am asking how it is resolved. there is no overlap of information too. the IACD is a mean to advertize adjustment capacity between two SC (so, by def. internal) that would otherwise be unknown and thus result in LSP blocking when crossing that LSR. i can give certain base rules of thumb for setting up values of IACD and its accounting (that is similar per nature to current Max LSP Bw) as part of the next revision but this is not going to prevent mis-configuration and/or misuse. -d. > A=20 >=20 >=20 From owner-ccamp@ops.ietf.org Sun Nov 2 11:08:04 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 A8EFD3A6B14 for ; Sun, 2 Nov 2008 11:08:04 -0800 (PST) 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 aatJG2ciYSwg for ; Sun, 2 Nov 2008 11:08:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7058E3A6B09 for ; Sun, 2 Nov 2008 11:08:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwiF0-000AkG-LE for ccamp-data@psg.com; Sun, 02 Nov 2008 19:04:02 +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 1KwiEs-000AjA-5E for ccamp@ops.ietf.org; Sun, 02 Nov 2008 19:03:58 +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 mA2J3mx9027248; Sun, 2 Nov 2008 19:03:48 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 mA2J3lRN027234; Sun, 2 Nov 2008 19:03:47 GMT Message-ID: <382FB452E844407982AC4889177536B7@your029b8cecfe> 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> <00275A5B436CA441900CB10936742A38014BA4AF@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38014BA566@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: MRN ext. doc Date: Sun, 2 Nov 2008 19:03:41 -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: Hello again, >>>>>> 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. [SNIP] >>> can u please use the ietf terminology at least to make the point >>> understandable to me (excuse my ignorance). what is a mapped >>> server ? >> >> OK. Well, I did try to explain in my previous response. [SNIP] > ok, i think i barely understood where you are heading at. now what is > the issue with the doc. ? honnestly, i do not catch the point you are > trying to make: section 4 addresses purely signaling procedure issue > (complements existing FA triggering/selection rules) and section 5 a > well-known TE problem that is how to attract traffic when no bearer is > setup (it is a particular case of the generic unknown adjcacency > problem). I didn't actually say there was anything wrong with the document :-) I just asked what I hoped was a simple question. >From our discussion it looks like the answer to my question was "yes". Let's move on. >>>>>> === >>>>>> 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. >>>> >>>> It doesn't make sense to use 11bbbbbb. [SNIP] >>> 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. >> >> I spoke to Lou. >> He had suggested 11bbbbbb because he thought the object might >> end up on a Path message. However, we don't think this would >> actually be the case because the call request message is a Notify. >> So he is more relaxed about this changing to 0bbbbbbb > > are call attributes mandatorily associated to calls (and which case > one could simply mandate support of the related attribute) and their > messaging/processing a must have feature of the protocol ? ... just to > be clear 0bbbbbbb does not solve the former. No, the Call_Attributes object is not mandatory on a Call request message (as currently defined). And yes, you are right, using 0bbbbbbb would not make it mandatory anyway. I am *only* concerned by how the call recipient will process the Notify, how (if?) they will respond, and whether this will waste processing in the network, especially at the call recipient. >>>>>> === >>>>>> 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. [SNIP] >>>> 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? >>> >>> 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 >> >> I agree completely. >> And that was my point. >> The call is a negotiation between end points about what >> connection will be set up, what adaptions will be applied, >> and what TE link will be created. >> This effectively requires the call request to state the set >> of potential adaptations, and the call response to identify >> the subset of acceptable adaptations. The connection can >> then be signaled in the correct switching type, and the >> resulting LSP can be associated to the TE link. > > per 4974, the LINK_CAPABILITY object can be used for > this purpose with subobject Type 65. > > i did not mention it for two reasons a) it is implicit in the > context (a Virtual Link by definition addresses the lowest SC > value) and b) part of the procedure referenced by this doc. Weeeeell... That use of Link Capability is not particularly clear in RFC 4974. According to section 4.3.3. of RFC 4974 this function allows the call initiator to list a set of switching capablities for links that connect it "to the network", and for the responder to reduce the list to those switching capablities that it supports. That is only half the function required. We also need to let the call responder know that we intend using the LSP to support a connection in a particular client layer/region. In other words, we have to specify what adaptation function we want the responder to support. It would be enough to add to the information already carried in the Link_Capablity object the link capability we intend to create. This could go in either the Link_Capablity object or in the Call_Attributes object. Oh, by the way, Link_Capability uses a CNum of type 0bbbbbb A From owner-ccamp@ops.ietf.org Sun Nov 2 16:36:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3257028C12A for ; Sun, 2 Nov 2008 16:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.244, 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 GTE0VGy6-CxP for ; Sun, 2 Nov 2008 16:36:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F67728C134 for ; Sun, 2 Nov 2008 16:35:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwnKj-000IXI-Df for ccamp-data@psg.com; Mon, 03 Nov 2008 00:30: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 1KwnKT-000IUa-Gg for ccamp@ops.ietf.org; Mon, 03 Nov 2008 00:30:07 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id C7A5F3A6A12; Sun, 2 Nov 2008 16:30:01 -0800 (PST) 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-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103003001.C7A5F3A6A12@core3.amsl.com> Date: Sun, 2 Nov 2008 16:30:01 -0800 (PST) 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-02.txt Pages : 15 Date : 2008-11-02 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-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-confirm-data-channel-status-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-02162726.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Nov 3 06:09: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 366DD3A6AF3 for ; Mon, 3 Nov 2008 06:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-0.721, 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 pXvENA29jhty for ; Mon, 3 Nov 2008 06:09:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CF923A687D for ; Mon, 3 Nov 2008 06:09:01 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwzyU-000LJx-Ks for ccamp-data@psg.com; Mon, 03 Nov 2008 14:00:10 +0000 Received: from [192.71.80.124] (helo=neo.viciousnest.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KwzyL-000LIJ-SG for ccamp@ops.ietf.org; Mon, 03 Nov 2008 14:00:04 +0000 Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id 2E94810C39; Mon, 3 Nov 2008 14:59:59 +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 19649-02; Mon, 3 Nov 2008 14:59:57 +0100 (CET) Received: from [192.36.157.201] (dhcp201.verkstad.net [192.36.157.201]) by neo.viciousnest.net (Postfix) with ESMTP id AE5AC10C1F; Mon, 3 Nov 2008 14:59:57 +0100 (CET) Message-ID: <490F03D6.30408@pi.nu> Date: Mon, 03 Nov 2008 14:59:50 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3 , L2VPN , ccamp , "ahtmpls@itu.int" , "mpls-tp@ietf.org" Subject: Poll for MPLS-TP documents to become mpls working group documents 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) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu From owner-ccamp@ops.ietf.org Mon Nov 3 07:18: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 5996728C283 for ; Mon, 3 Nov 2008 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[AWL=-1.673, 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 sDCD9LRiSePw for ; Mon, 3 Nov 2008 07:18:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A50AA28C298 for ; Mon, 3 Nov 2008 07:16:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx151-0007HF-OK for ccamp-data@psg.com; Mon, 03 Nov 2008 15:10:59 +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 1Kx14w-0007Fc-Ud for ccamp@ops.ietf.org; Mon, 03 Nov 2008 15:10:57 +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 mA3FAoaq023072 for ; Mon, 3 Nov 2008 15:10:50 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 mA3FAnPo023046 for ; Mon, 3 Nov 2008 15:10:49 GMT Message-ID: <955F6D91F9074267920C29ABF7E129EE@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft agenda Date: Mon, 3 Nov 2008 15:10:44 -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, Based on requests received and a few additional things we think ought to be covered, we have put together a DRAFT agenda which you can see at http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm Comments please. Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Mon Nov 3 07:53: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 961B33A6950 for ; Mon, 3 Nov 2008 07:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKow5RpOYc5K for ; Mon, 3 Nov 2008 07:53:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 760F93A6A1F for ; Mon, 3 Nov 2008 07:53:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx1fO-000D5A-15 for ccamp-data@psg.com; Mon, 03 Nov 2008 15:48:34 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx1fI-000D2b-2O for ccamp@ops.ietf.org; Mon, 03 Nov 2008 15:48:31 +0000 X-IronPort-AV: E=Sophos;i="4.33,536,1220227200"; d="scan'208";a="26545537" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Nov 2008 15:48:27 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA3FmQlB020384; Mon, 3 Nov 2008 10:48:27 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA3FmPgW024336; Mon, 3 Nov 2008 15:48:27 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); Mon, 3 Nov 2008 10:48:26 -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] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 10:47:50 -0500 Message-ID: In-Reply-To: <490F03D6.30408@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vMqvzRuqx0AQToiUtY5hN6mruwACtm2w References: <490F03D6.30408@pi.nu> From: "Zafar Ali (zali)" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , X-OriginalArrivalTime: 03 Nov 2008 15:48:26.0503 (UTC) FILETIME=[9C334170:01C93DCB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2541; t=1225727307; x=1226591307; c=relaxed/simple; s=rtpdkim1001; 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=20[mpls]=20Poll=20for=20MPLS-TP=20documen ts=20to=20become=20mpls=20working=20groupdocuments |Sender:=20 |To:=20=22Loa=20Andersson=22=20,=20,=20=22pwe3=22=20,=0A=20=20=20=20=20=20=20= 20=22L2VPN=22=20,=20=22ccamp=22=20,=0A=20=20=20=20=20=20=20=20,=20< mpls-tp@ietf.org>; bh=dSJ0yOw52Vw8rXs75LMFQ8YiUwKPlN+ZW3lKtYHpjZc=; b=Bf0MRjQ7JZHF6Aanj3VqKvjH7n4FieBVCcBjYh4RF6jiPiZGtIDSaQ9tg9 UM8mWwDSp1GMSh+R7rO7L5F/Cwe0dcqDNvPahz1Xtmi6wY6nARQv+JXUwdB5 1V3yPHb+uQ; Authentication-Results: rtp-dkim-1; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Loa-=20 In favor for all drafts to become WG docs.=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Monday, November 03, 2008 9:00 AM > To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int;=20 > mpls-tp@ietf.org > Subject: [mpls] Poll for MPLS-TP documents to become mpls=20 > working groupdocuments >=20 > Working group(s) >=20 > we have four documents from the MPLS-TP effort that the=20 > authors think are ready to become working group documents.=20 > The documents are listed below. >=20 > This mail initiate a two week working poll for comments on=20 > three of the documents, for the fourth document > (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. >=20 > Please send your comments before Nov 11 for=20 > draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- >=20 > *Note:* > Please send your responses to the *mpls working group mailing=20 > list*, a bit of discipline is needed, "replay all" won't do=20 > the trick ;). >=20 > Comments Nov 11 the latest: >=20 > Title : MPLS Generic Associated Channel > Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, > R. Aggarwal > Filename : draft-bocci-mpls-tp-gach-gal-00.txt > Pages : 16 > Date : 2008-10-27 >=20 >=20 > Comments Nov 17 the latest: >=20 > Title : MPLS-TP Requirements > Author(s): B. Niven-Jenkins, et al. > Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt > Pages : 18 > Date : 2008-10-31 >=20 > Title : A Framework for MPLS in Transport Networks > Author(s): M. Bocci, S. Bryant > Filename : draft-blb-mpls-tp-framework-01.txt > Pages : 27 > Date : 2008-10-31 >=20 > Title : Requirements for OAM in MPLS Transport Networks > Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi > Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt > Pages : 16 > Date : 2008-11-1 >=20 > Loa and George >=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 Mon Nov 3 08:07:50 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 6301B3A68B0 for ; Mon, 3 Nov 2008 08:07:50 -0800 (PST) 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.701, 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 OZunI2r9NSWT for ; Mon, 3 Nov 2008 08:07:49 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F1DD3A6BBC for ; Mon, 3 Nov 2008 08:06:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx1r2-000El9-Ni for ccamp-data@psg.com; Mon, 03 Nov 2008 16:00:36 +0000 Received: from [143.209.238.159] (helo=audl952.usa.alcatel.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx1qt-000Ej1-Ua for ccamp@ops.ietf.org; Mon, 03 Nov 2008 16:00:30 +0000 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id mA3Fxuge001774; Mon, 3 Nov 2008 09:59:56 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 3 Nov 2008 09:59:56 -0600 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] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 09:59:55 -0600 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04C95BFE@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <490F03D6.30408@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vM/bULPCz8SJTFOBGgynqGwEfAAEGBrA References: <490F03D6.30408@pi.nu> From: "AISSAOUI Mustapha" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , X-OriginalArrivalTime: 03 Nov 2008 15:59:56.0440 (UTC) FILETIME=[376F4980:01C93DCD] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: support all. Mustapha.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Monday, November 03, 2008 9:00 AM > To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int;=20 > mpls-tp@ietf.org > Subject: [mpls] Poll for MPLS-TP documents to become mpls=20 > working groupdocuments >=20 > Working group(s) >=20 > we have four documents from the MPLS-TP effort that the=20 > authors think are ready to become working group documents.=20 > The documents are listed below. >=20 > This mail initiate a two week working poll for comments on=20 > three of the documents, for the fourth document > (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. >=20 > Please send your comments before Nov 11 for=20 > draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- >=20 > *Note:* > Please send your responses to the *mpls working group mailing=20 > list*, a bit of discipline is needed, "replay all" won't do=20 > the trick ;). >=20 > Comments Nov 11 the latest: >=20 > Title : MPLS Generic Associated Channel > Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, > R. Aggarwal > Filename : draft-bocci-mpls-tp-gach-gal-00.txt > Pages : 16 > Date : 2008-10-27 >=20 >=20 > Comments Nov 17 the latest: >=20 > Title : MPLS-TP Requirements > Author(s): B. Niven-Jenkins, et al. > Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt > Pages : 18 > Date : 2008-10-31 >=20 > Title : A Framework for MPLS in Transport Networks > Author(s): M. Bocci, S. Bryant > Filename : draft-blb-mpls-tp-framework-01.txt > Pages : 27 > Date : 2008-10-31 >=20 > Title : Requirements for OAM in MPLS Transport Networks > Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi > Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt > Pages : 16 > Date : 2008-11-1 >=20 > Loa and George >=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 Mon Nov 3 08:49:49 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 4D6AE3A690A for ; Mon, 3 Nov 2008 08:49:49 -0800 (PST) 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.701, 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 FiFTUD1Vvn7r for ; Mon, 3 Nov 2008 08:49:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 634E53A6896 for ; Mon, 3 Nov 2008 08:49:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx2Wg-000LhD-Pe for ccamp-data@psg.com; Mon, 03 Nov 2008 16:43:38 +0000 Received: from [135.245.0.37] (helo=ihemail3.lucent.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx2Wb-000LfD-KA for ccamp@ops.ietf.org; Mon, 03 Nov 2008 16:43:36 +0000 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mA3Gh8lV002971; Mon, 3 Nov 2008 10:43:12 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 10:43:10 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 22:13:07 +0530 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: Poll for MPLS-TP documents to become mpls working group documents Date: Mon, 3 Nov 2008 22:13:05 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965021D78F8@INEXC1U01.in.lucent.com> In-Reply-To: <490F03D6.30408@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for MPLS-TP documents to become mpls working group documents thread-index: Ack9vI5OU+9/OWbJRrGHPlXvQ+wV6AAFp9ag References: <490F03D6.30408@pi.nu> From: "Dutta, Pranjal K \(Pranjal\)" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , X-OriginalArrivalTime: 03 Nov 2008 16:43:07.0889 (UTC) FILETIME=[400F0610:01C93DD3] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support for all. Thanks, Pranjal=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, November 03, 2008 6:00 AM To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: Poll for MPLS-TP documents to become mpls working group documents Working group(s) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu From owner-ccamp@ops.ietf.org Mon Nov 3 09:55:17 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1863A6B97 for ; Mon, 3 Nov 2008 09:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-0.408, 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 oh-PdxSARCKd for ; Mon, 3 Nov 2008 09:55:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0104C3A6940 for ; Mon, 3 Nov 2008 09:55:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx3YB-000532-7x for ccamp-data@psg.com; Mon, 03 Nov 2008 17:49:15 +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 1Kx3Y5-000528-US for ccamp@ops.ietf.org; Mon, 03 Nov 2008 17:49:12 +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 mA3Hmf3S002689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Nov 2008 18:48:41 +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 mA3Hmfv1017908; Mon, 3 Nov 2008 18:48:41 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 18:48:40 +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: [mpls-tp] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 18:48:37 +0100 Message-ID: <43284B5A95E36B4AB4A91EBA4E0FC31EECCB64@DEMUEXC030.nsn-intra.net> In-Reply-To: <490F03D6.30408@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vOlzwcsBl3UNRy2LKuiue/RPHgAH3Sgg References: <490F03D6.30408@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , X-OriginalArrivalTime: 03 Nov 2008 17:48:40.0951 (UTC) FILETIME=[6858A870:01C93DDC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support for all. -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Monday, November 03, 2008 16:00 To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: [mpls-tp] Poll for MPLS-TP documents to become mpls working groupdocuments Working group(s) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George --=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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From owner-ccamp@ops.ietf.org Mon Nov 3 10:19:56 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 35C0F3A686D for ; Mon, 3 Nov 2008 10:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.237, 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 FgKLYXC+BGhc for ; Mon, 3 Nov 2008 10:19:55 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 373E828C200 for ; Mon, 3 Nov 2008 10:19:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx3xE-00089O-Qs for ccamp-data@psg.com; Mon, 03 Nov 2008 18:15: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 1Kx3x6-000889-OX for ccamp@ops.ietf.org; Mon, 03 Nov 2008 18:15:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 515243A686D; Mon, 3 Nov 2008 10:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rwa-info-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103181501.515243A686D@core3.amsl.com> Date: Mon, 3 Nov 2008 10:15:01 -0800 (PST) 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 : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-info-01.txt Pages : 17 Date : 2008-11-03 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs, particularly in cases where there are no or a limited number of wavelength converters available. This model currently does not include optical impairments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-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-rwa-info-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03100105.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Nov 3 11:04:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655063A6BBA for ; Mon, 3 Nov 2008 11:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.236, 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 G4QXGHh8v5lc for ; Mon, 3 Nov 2008 11:04:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B67328C0FA for ; Mon, 3 Nov 2008 11:04:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx4el-000Bs7-87 for ccamp-data@psg.com; Mon, 03 Nov 2008 19:00:07 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx4ef-000BrB-8Q for ccamp@ops.ietf.org; Mon, 03 Nov 2008 19:00:04 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id D5F203A6BF6; Mon, 3 Nov 2008 11:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103190001.D5F203A6BF6@core3.amsl.com> Date: Mon, 3 Nov 2008 11:00:01 -0800 (PST) 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 : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) Author(s) : D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Roux, E. Oki, I. Inoue, E. Dotaro, G. Grammel Filename : draft-ietf-ccamp-gmpls-mln-extensions-03.txt Pages : 21 Date : 2008-11-3 There are requirements for the support of networks comprising LSRs with different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer/Multi- Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-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-mln-extensions-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3105108.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Nov 3 11:50:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292C428C247 for ; Mon, 3 Nov 2008 11:50:13 -0800 (PST) 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 9Cvtocgtstv9 for ; Mon, 3 Nov 2008 11:50:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 378FB28C20F for ; Mon, 3 Nov 2008 11:50:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx5MS-000GR3-OV for ccamp-data@psg.com; Mon, 03 Nov 2008 19:45:17 +0000 Received: from [63.118.34.24] (helo=ripley.ciena.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kx5MO-000GQI-06 for ccamp@ops.ietf.org; Mon, 03 Nov 2008 19:45:13 +0000 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] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 14:44:58 -0500 Message-ID: <6535C9CED6F87446B41D20EF170F23621385AC@mamxm01.ciena.com> In-Reply-To: <490F03D6.30408@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vNVtCHsPlZ7CSQKUEf/VFXm4wAAL8wFQ References: <490F03D6.30408@pi.nu> From: "Shah, Himanshu" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , X-OriginalArrivalTime: 03 Nov 2008 19:45:26.0676 (UTC) FILETIME=[B8157540:01C93DEC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: support all. /himanshu=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, November 03, 2008 9:00 AM To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Working group(s) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From owner-ccamp@ops.ietf.org Tue Nov 4 03:13:49 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 827193A6A80 for ; Tue, 4 Nov 2008 03:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izeQXN8dlNal for ; Tue, 4 Nov 2008 03:13:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A254D3A6A4D for ; Tue, 4 Nov 2008 03:13:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KxJl5-000J5R-GV for ccamp-data@psg.com; Tue, 04 Nov 2008 11:07:39 +0000 Received: from [133.145.228.5] (helo=mail4.hitachi.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KxJkw-000J43-Nb for ccamp@ops.ietf.org; Tue, 04 Nov 2008 11:07:34 +0000 Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id DFC9733CC5 for ; Tue, 4 Nov 2008 20:07:26 +0900 (JST) Received: from MFILTER-S3.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id mA4B7QOE015235; Tue, 4 Nov 2008 20:07:26 +0900 Received: from vshuts2.hitachi.co.jp (unverified) by MFILTER-S3.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Tue, 4 Nov 2008 20:07:26 +0900 X-AuditID: 0ac90647-a8e4cba00000286d-7c-49102ceeccc4 Received: from gmml23.itg.hitachi.co.jp (unknown [158.213.165.143]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 77E1D8B0163; Tue, 4 Nov 2008 20:07:26 +0900 (JST) Received: from [127.0.0.1] by gmml23.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id mA4B7Q220041968; Tue, 4 Nov 2008 20:07:26 +0900 Message-ID: <49102CDC.6090404@hitachi.com> Date: Tue, 04 Nov 2008 20:07:08 +0900 From: Masahiko Mizutani User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" , pwe3 , L2VPN , ccamp , "ahtmpls@itu.int" , "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Poll for MPLS-TP documents to become mpls working group documents References: <490F03D6.30408@pi.nu> In-Reply-To: <490F03D6.30408@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support all documents. Regards, Masahiko Mizutani Loa Andersson wrote: > Working group(s) > > we have four documents from the MPLS-TP effort that the authors think > are ready to become working group documents. The documents are listed below. > > This mail initiate a two week working poll for comments on three of the > documents, for the fourth document > (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. > > Please send your comments before Nov 11 for > draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- > > *Note:* > Please send your responses to the *mpls working group mailing list*, > a bit of discipline is needed, "replay all" won't do the trick ;). > > Comments Nov 11 the latest: > > Title : MPLS Generic Associated Channel > Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, > R. Aggarwal > Filename : draft-bocci-mpls-tp-gach-gal-00.txt > Pages : 16 > Date : 2008-10-27 > > > Comments Nov 17 the latest: > > Title : MPLS-TP Requirements > Author(s): B. Niven-Jenkins, et al. > Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt > Pages : 18 > Date : 2008-10-31 > > Title : A Framework for MPLS in Transport Networks > Author(s): M. Bocci, S. Bryant > Filename : draft-blb-mpls-tp-framework-01.txt > Pages : 27 > Date : 2008-10-31 > > Title : Requirements for OAM in MPLS Transport Networks > Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi > Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt > Pages : 16 > Date : 2008-11-1 > > Loa and George > From owner-ccamp@ops.ietf.org Thu Nov 6 10:14:08 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B75A3A693B for ; Thu, 6 Nov 2008 10:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 s3U+SEpbH-U3 for ; Thu, 6 Nov 2008 10:14:07 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82D533A6825 for ; Thu, 6 Nov 2008 10:14:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ky9GG-000GkQ-AH for ccamp-data@psg.com; Thu, 06 Nov 2008 18:07:16 +0000 Received: from [143.209.238.159] (helo=audl952.usa.alcatel.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ky9GA-000GjU-OK for ccamp@ops.ietf.org; Thu, 06 Nov 2008 18:07:13 +0000 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id mA6I5Wd7013231; Thu, 6 Nov 2008 12:05:32 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 6 Nov 2008 12:05:32 -0600 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] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Thu, 6 Nov 2008 12:04:48 -0600 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04D070A8@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbAAAD+ZwA= References: From: "AISSAOUI Mustapha" To: "Zafar Ali \(zali\)" , "Lou Berger" Cc: , "Newton, Jonathan" , , , "Anca Zamfir \(ancaz\)" X-OriginalArrivalTime: 06 Nov 2008 18:05:32.0375 (UTC) FILETIME=[4270F670:01C9403A] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Ali, I have an issue with not providing backwards compatibility with the "Notify" error code and the error sub-codes for link and node maintenance defined in RFC 4736. This draft has been using these codes for almost four years now and it is not acceptable they get changed in last call. Furthermore, draft-ietf-mpls-gmpls-lsp-reroute-02.txt suggests backwards compatibility must be provided when required. I believe this is one of those cases. When draft-ietf-mpls-gmpls-lsp-reroute-02.txt passes WG last call, it makes perfect sense to require new applications to start using it. Regards, Mustapha.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Zafar Ali (zali) > Sent: Wednesday, October 29, 2008 12:35 PM > To: Lou Berger > Cc: mpls@ietf.org; Newton, Jonathan; jpv@cisco.com;=20 > ccamp@ops.ietf.org; Anca Zamfir (ancaz) > Subject: Re: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown >=20 > Hi Lou- =20 >=20 > > -----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;=20 > > 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)? =20 > Is it that=20 > > the reroute document isn't sufficient clear on how to=20 > indicated each=20 > > of the 4? Is it some other reason? > >=20 >=20 > This is because headend may be able to compute alternate=20 > route ("reroute" action) for mb4b differently, depending on=20 > the resource under graceful shutdown, as detailed in the=20 > document. Hence one code is define for TE node, TE link,=20 > component link of a bundled TE link, and label resource, each.=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From owner-ccamp@ops.ietf.org Thu Nov 6 13:35: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 191D83A6AC6 for ; Thu, 6 Nov 2008 13:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.99 X-Spam-Level: X-Spam-Status: No, score=-4.99 tagged_above=-999 required=5 tests=[AWL=-1.095, 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 sSciDDc6qBCY for ; Thu, 6 Nov 2008 13:35:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6C9E3A6A70 for ; Thu, 6 Nov 2008 13:35:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KyCNa-0006Cj-NE for ccamp-data@psg.com; Thu, 06 Nov 2008 21:27:02 +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 1KyCNT-0006Bj-SF for ccamp@ops.ietf.org; Thu, 06 Nov 2008 21:26:59 +0000 X-IronPort-AV: E=Sophos;i="4.33,559,1220227200"; d="scan'208";a="27016702" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Nov 2008 21:26:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA6LQscl009421; Thu, 6 Nov 2008 16:26:54 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA6LQsoL016002; Thu, 6 Nov 2008 21:26:54 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 16:26:54 -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] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Thu, 6 Nov 2008 16:26:54 -0500 Message-ID: In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B04D070A8@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbAAAD+ZwABm7fF0A== References: <4A5028372622294A99B8FFF6BD06EB7B04D070A8@USDALSMBS03.ad3.ad.alcatel.com> From: "Zafar Ali (zali)" To: "AISSAOUI Mustapha" , "Lou Berger" Cc: , "Newton, Jonathan" , , , "Anca Zamfir (ancaz)" X-OriginalArrivalTime: 06 Nov 2008 21:26:54.0653 (UTC) FILETIME=[640A46D0:01C94056] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2949; t=1226006814; x=1226870814; 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:=20RE=3A=20[mpls]=20Updates=20to=20draft-ietf-ccam p-mpls-graceful-shutdown |Sender:=20 |To:=20=22AISSAOUI=20Mustapha=22=20,=0A=20=20=20=20=20=20=20=20=22Lou=20Berger=22 =20; bh=M/y1Y3DEF7WpFFRoHyiGwMhBHZGmdpTLsajBG5IfaSs=; b=F42WUN+I/O5hU7OyLFzyeZatIHzrODeZKNdJPMw/xTYcB0BofsakrQ+lpx fPwwOqSTHwAEzi6ozS3VDp1oNTofeRohkpXo1NJCIoNl0JIxkDY/2s+sXcpb /saV+nwRhM; 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: Mustapha-=20 I think once we address Lou's comment, that will also address your comment. So please wait for the new revision. We can try to publish it during the IETF week.=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel-lucent.com]=20 > Sent: Thursday, November 06, 2008 1:05 PM > To: Zafar Ali (zali); Lou Berger > Cc: mpls@ietf.org; Newton, Jonathan; jpv@cisco.com;=20 > ccamp@ops.ietf.org; Anca Zamfir (ancaz) > Subject: RE: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown >=20 > Hi Ali, > I have an issue with not providing backwards compatibility=20 > with the "Notify" error code and the error sub-codes for link=20 > and node maintenance defined in RFC 4736. This draft has been=20 > using these codes for almost four years now and it is not=20 > acceptable they get changed in last call. >=20 > Furthermore, draft-ietf-mpls-gmpls-lsp-reroute-02.txt=20 > suggests backwards compatibility must be provided when=20 > required. I believe this is one of those cases. When=20 > draft-ietf-mpls-gmpls-lsp-reroute-02.txt passes WG last call,=20 > it makes perfect sense to require new applications to start using it. >=20 > Regards, > Mustapha.=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > > Of Zafar Ali (zali) > > Sent: Wednesday, October 29, 2008 12:35 PM > > To: Lou Berger > > Cc: mpls@ietf.org; Newton, Jonathan; jpv@cisco.com;=20 > > ccamp@ops.ietf.org; Anca Zamfir (ancaz) > > Subject: Re: [mpls] Updates to=20 > draft-ietf-ccamp-mpls-graceful-shutdown > >=20 > > Hi Lou- > >=20 > > > -----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;=20 > > > 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)? =20 > > Is it that > > > the reroute document isn't sufficient clear on how to > > indicated each > > > of the 4? Is it some other reason? > > >=20 > >=20 > > This is because headend may be able to compute alternate route=20 > > ("reroute" action) for mb4b differently, depending on the resource=20 > > under graceful shutdown, as detailed in the document. Hence=20 > one code=20 > > is define for TE node, TE link, component link of a bundled=20 > TE link,=20 > > and label resource, each. > >=20 > > Thanks > >=20 > > Regards... Zafar > >=20 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > >=20 >=20 From owner-ccamp@ops.ietf.org Fri Nov 7 11:37:21 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 8F39E3A6B7E for ; Fri, 7 Nov 2008 11:37:21 -0800 (PST) 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.617, BAYES_50=0.001, 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 mrXbSxR96Qp4 for ; Fri, 7 Nov 2008 11:37:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1943C3A6AE2 for ; Fri, 7 Nov 2008 11:37:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KyX0v-000FL3-7o for ccamp-data@psg.com; Fri, 07 Nov 2008 19:29:01 +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 1KyX0p-000FKJ-EY for ccamp@ops.ietf.org; Fri, 07 Nov 2008 19:28:58 +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 mA7JSpmB015269 for ; Fri, 7 Nov 2008 19:28:52 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 mA7JSpVZ015263 for ; Fri, 7 Nov 2008 19:28:51 GMT Message-ID: <984EFCBC86A84BD59181C6E179499780@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <955F6D91F9074267920C29ABF7E129EE@your029b8cecfe> Subject: Agenda updated Date: Fri, 7 Nov 2008 19:28:46 -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: I have made some updates. http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm Please shout if there further issues. Thanks, Adrian From owner-ccamp@ops.ietf.org Sun Nov 9 05:22:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB923A68FF for ; Sun, 9 Nov 2008 05:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.594 X-Spam-Level: X-Spam-Status: No, score=0.594 tagged_above=-999 required=5 tests=[AWL=-1.512, 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 YT1lVaJo4oQb for ; Sun, 9 Nov 2008 05:22:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 936843A6824 for ; Sun, 9 Nov 2008 05:22:37 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KzA9I-000Azz-Uw for ccamp-data@psg.com; Sun, 09 Nov 2008 13:16:16 +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 1KzA9E-000Ayz-9Q for ccamp@ops.ietf.org; Sun, 09 Nov 2008 13:16:14 +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 mA9DG8hn009608 for ; Sun, 9 Nov 2008 13:16:08 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 mA9DG81q009602 for ; Sun, 9 Nov 2008 13:16:08 GMT Message-ID: <8FCD06A61E6C40518AF2E84A0E30F1C0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Slides Date: Sun, 9 Nov 2008 13:16:02 -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: Please start sending in your slides so that I can post them for everyone to see. Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Nov 10 11:38:23 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 0DD923A6A94 for ; Mon, 10 Nov 2008 11:38:23 -0800 (PST) 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 1OIce7HWQNiB for ; Mon, 10 Nov 2008 11:38:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7F953A68A0 for ; Mon, 10 Nov 2008 11:38:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KzcUo-000AVD-GK for ccamp-data@psg.com; Mon, 10 Nov 2008 19:32:22 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KzcUi-000AU5-5e for ccamp@ops.ietf.org; Mon, 10 Nov 2008 19:32:18 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id BC1BB3A6A9F; Mon, 10 Nov 2008 11:32:17 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Protocol Action: 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE' to Proposed Standard Message-Id: <20081110193217.BC1BB3A6A9F@core3.amsl.com> Date: Mon, 10 Nov 2008 11:32:17 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: The IESG has approved the following document: - 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE ' 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-rfc4420bis-03.txt Technical Summary This document replaces and obsoletes RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. This allows consistency with the use of TLV data structures in other related documents, and therefore essentially corrects a bug in 4420. Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. Working Group Summary This document corrects a bug in RFC4220 which was found during interoperability testing. Once this bug was found, there was no controversy regarding how to fix this. Document Quality Current implementations are compatible with this document (and therefore no longer compatible with one detail in RFC4220). Personnel Deborah Brungard is the document shepherd. Ross Callon is the responsible AD. RFC Editor Note Please update section 3 as follows: OLD Length Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four- octet aligned. Value The data for the TLV padded as described above. NEW Length Indicates the total length of the TLV in octets. That is the combined length of the Type, Length, and Value fields, i.e., four plus the length of the Value field in octets. The entire TLV MUST be padded with between zero and three trailing zeros to make it four-octet aligned. The Length field does not count any padding. Value The data carried in the TLV. From owner-ccamp@ops.ietf.org Tue Nov 11 00:48: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 AFE783A6974 for ; Tue, 11 Nov 2008 00:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, 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 VtwfpIJermjC for ; Tue, 11 Nov 2008 00:48:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DF153A6848 for ; Tue, 11 Nov 2008 00:48:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kzoq8-000Fb9-KH for ccamp-data@psg.com; Tue, 11 Nov 2008 08:43:12 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kzoq2-000Fae-Ig for ccamp@ops.ietf.org; Tue, 11 Nov 2008 08:43:10 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7197C21FF1; Tue, 11 Nov 2008 09:41:41 +0100 (CET) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-67-49194544bef1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8FF7321E5B; Tue, 11 Nov 2008 09:41:40 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 09:41:40 +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: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Tue, 11 Nov 2008 09:41:39 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E91057D04A8@esealmw116.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt thread-index: Ack6AA/bxf8lkrpkSMuljVMOwLadUQJ2R12g References: From: "Attila Takacs" To: "Don Fedyk" , , "Loa Andersson" Cc: "Adrian Farrel" , X-OriginalArrivalTime: 11 Nov 2008 08:41:40.0038 (UTC) FILETIME=[50DCC660:01C943D9] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi all, Some comments on the draft, mostly editorial. Best regards, Attila -Move the abbreviation section (2.3.2) in the beginning of the document. I would consider moving the whole terminology section (2.3) forward. -Page 3, delete "Document History" -Page 3, Introduction, last sentence of second paragraph, change "but not an explicitly" ->"but not on explicitly" -Page 3, Introduction, 5th paragraph: add a new reference to 802.1ad and reword the first sentence -Page 4, last paragraph change: "This document introduces and explains the concept of an Ethernet Label Switched Path (Eth-LSP)." -> "This document introduces and explains GMPLS control plane deployment for Ethernet and the concept of the Ethernet Label Switched Path (Eth-LSP)." -Page 5, Background, second paragraph, first sentence change: "this section is based on the on-going work" -> "this section is based on both finished and on-going work" -Page 7, bullet on I-tagged interfaces, change second sentence: "An I-Tag contains a service identifier (24 bit I-SID) and priority markings as well as some other flags." -> "An I-Tag contains a service identifier (24 bit I-SID) and priority markings as well as some other fields." -Page 7, first paragraph after the bullet list, change: "In general, the different switching type determines" -> "In general, the switching type determines" and "The type may also" -> "The switching type may also" -Page 7, last paragraph, delete: "For the Eth-LSP unicast mode of behavior, the hardware performs unicast packet forwarding of known MAC addresses leveraging existing Ethernet forwarding." -Page 8, OAM, last paragraph, reword to: "Both Y.1731 & 802.1ag assumes that bidirectional transactions (e.g., LBM/LBR) use the same VID in both directions. However in some scenarios, especially with explicitly routed paths [802.1Qay], it is possible that different VIDs are used upstream and downstream. In the context of [802.1Qay] work is ongoing to update [802.1ag] to support such scenarios."=20 -Page 8, Bi-directional Congruent LSP, typo, "LSP shared" -> "LSP shares" -Page 8, Shared forwarding: add at the end: "In contrast to merging where control plane states as well as forwarding entries are merged, with shared forwarding dedicated states for all Eth-LSP are maintained regardless of shared forwarding entries." -Page 8, add the definition of Eth-LSPs: "Eth-LSP: This term refers to Ethernet service paths that are controlled via GMPLS." -Page 10, Framework, first sentence: remove parenthesis around GMPLS -Page 12, first paragraph reorder to read: "...This valid MAC checking and broadcast supports Ethernet learning. A special case is when a VID is defined for only two ports on one bridge, effectively resulting in a p2p forwarwading constraint, in this case all frames tagged with that VID received over one of these ports are forward over the other port without address learning. [802.1Qay] allows for turning off learning and hence the broadcast mechanism providing means to create explicitly routed Ethernet connections." -Page 16, section 8, delete last sentence "More detail will be added to the section in a later revision." and/or add further details :-) =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, October 29, 2008 8:48 PM > To: ccamp@ops.ietf.org > Subject: Two week last call on=20 > draft-ietf-ccamp-gmpls-ethernet-arch-03.txt >=20 > This email starts a two week working group last call on=20 > "GMPLS Ethernet Label Switching Architecture and Framework" >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth > ernet-arch-03.txt >=20 > The I-D is marked as Informational. >=20 > Please send your comments to the list by 12 noon GMT Friday=20 > 14th November. >=20 > Thanks, > Adrian and Deborah=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Nov 11 16:15:00 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 3E2E328C150 for ; Tue, 11 Nov 2008 16:15:00 -0800 (PST) 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 aM5KvVZWFECI for ; Tue, 11 Nov 2008 16:14:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55D483A6832 for ; Tue, 11 Nov 2008 16:14:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L03I9-000LJ8-2f for ccamp-data@psg.com; Wed, 12 Nov 2008 00:09:05 +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 1L03Hx-000LAq-Ar for ccamp@ops.ietf.org; Wed, 12 Nov 2008 00:08:57 +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 mAC08nUt032025 for ; Wed, 12 Nov 2008 00:08:49 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 mAC08nDa032019 for ; Wed, 12 Nov 2008 00:08:49 GMT Message-ID: <56BC37215ECA446B84C9DB2EDEC1969D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: NOTE WELL: New Boilerplate Text Required for all new Submissions to IETF Date: Wed, 12 Nov 2008 00:08:22 -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: Note well. Your I-Ds will not be posted unless they conform to new boiler-plate requirements. Adrian ----- Original Message ----- From: "Ed Juskevicius" To: "IETF Discussion" ; ; ; ; ; "RFC Editor" ; Cc: Sent: Tuesday, November 11, 2008 11:03 PM Subject: Announcement: New Boilerplate Text Required for all new Submissionsto IETF > Greetings. This message is to draw your attention to the significance > of the publication of RFC5377 and RFC5378 earlier today. > > * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be > Granted in IETF Documents > * RFC5378 is Rights Contributors Provide to the IETF Trust > > Note that RFC5378 is also BCP0078. RFC5378 is an update to RFC2026, and > RFC5378 obsoletes both RFC3978 and RFC4748. > > Coincident with the above, the IETF Trustees have posted a new policy > document with guidance to the community on: > * Legal Provisions Relating to IETF Documents at > http://trustee.ietf.org/license-info/ > > Taken as a set, the documents listed above specify changes that are now > required in all new submissions into the IETF. > > Henrik Levkowetz has updated the idnit tool and AMS have updated the > Internet-Draft submission tool to reflect the new requirements. An > update to the xml2rfc has been requested. > > Please review the "Legal Provisions Relating to IETF Documents" and > RFC5378 to discover the new boilerplate text that is now required. > Please also take action to update the tools you use for creating your > documents. > > New submissions using either the old or the new boilerplate text will be > accepted starting today, until 01h00 UTC on December 16th, 2008. After > this cutoff date, all new submissions will be required to use ONLY the > new boilerplate text. All submissions using old boilerplate text after > the cutoff date will be rejected. > > Regards and FYI. > > Ed Juskevicius > IETF Trust Chair > edj@nortel.com > > p.s. - Don't be surprised if you see periodic reminders about this as we > approach December 16th. From owner-ccamp@ops.ietf.org Wed Nov 12 07:05: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 257B03A67F0 for ; Wed, 12 Nov 2008 07:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, 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 fJr1q5CYuXyr for ; Wed, 12 Nov 2008 07:05:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8C0B3A68DC for ; Wed, 12 Nov 2008 07:05:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0HBk-000DFQ-DY for ccamp-data@psg.com; Wed, 12 Nov 2008 14:59:24 +0000 Received: from [217.115.75.234] (helo=demumfd002.nsn-inter.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0HBd-000DEY-DK for ccamp@ops.ietf.org; Wed, 12 Nov 2008 14:59:20 +0000 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mACEwXRM008432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Nov 2008 15:58:33 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mACEwVJh000513; Wed, 12 Nov 2008 15:58:32 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 15:58:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls workinggroupdocuments Date: Wed, 12 Nov 2008 15:58:28 +0100 Message-ID: <43284B5A95E36B4AB4A91EBA4E0FC31EF251AE@DEMUEXC030.nsn-intra.net> In-Reply-To: <93DFCD4B101EB440B5B72997456C5F9402E11185@esealmw118.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls workinggroupdocuments Thread-Index: Ack9vNPuOTzVZoPIS8u3G2GbWI2bwAG/pBpwAAawcoA= References: <490F03D6.30408@pi.nu> <93DFCD4B101EB440B5B72997456C5F9402E11185@esealmw118.eemea.ericsson.se> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Annamaria Fulignoli" , "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , X-OriginalArrivalTime: 12 Nov 2008 14:58:29.0530 (UTC) FILETIME=[1F9537A0:01C944D7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: I have also issued a few weeks ago some comments and questions on the = framework. I hope the editors will address these comments.=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of ext Annamaria Fulignoli Sent: Wednesday, November 12, 2008 13:45 To: Loa Andersson; mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; = mpls-tp@ietf.org Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls = workinggroupdocuments Hi all, I support for all the four. However I wonder if it's possible to have some more clarification now = about draft-blb-mpls-tp-framework-01, Figure 3 and associated Editor's = note: "The figure above arose from discussions in the MPLS-TP design team. It = will be clarified in a future version of this draft" It's not clear to me the issue regarding OAM dmux without GAL/GACH.=20 My understanding was that:=20 "OAM, protection and forwarding of data packets MUST be able to operate = without IP forwarding support " as reported by the same draft section 2 and "... the operation of OAM functions MUST NOT rely on IP routing and = forwarding capabilities" as reported by draft-vigoureux-mpls-tp-oam-requirements-01 (section 2.1) Thank you and Best Regards Annamaria -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Loa Andersson Sent: luned=EC 3 novembre 2008 15.00 To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: [mpls] Poll for MPLS-TP documents to become mpls working = groupdocuments Working group(s) we have four documents from the MPLS-TP effort that the authors think = are ready to become working group documents. The documents are listed = below. This mail initiate a two week working poll for comments on three of the = documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for = draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a = bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- 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 = _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From owner-ccamp@ops.ietf.org Fri Nov 14 03:42:50 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 0C31F3A6A69 for ; Fri, 14 Nov 2008 03:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 FvO9vxC07p7n for ; Fri, 14 Nov 2008 03:42:49 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 89DA13A67C0 for ; Fri, 14 Nov 2008 03:42:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0wwZ-00073a-O5 for ccamp-data@psg.com; Fri, 14 Nov 2008 11:34:31 +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 1L0wwT-00072s-Dy for ccamp@ops.ietf.org; Fri, 14 Nov 2008 11:34:28 +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 mAEBYIp5008104 for ; Fri, 14 Nov 2008 11:34:21 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 mAEBYH2d008083 for ; Fri, 14 Nov 2008 11:34:18 GMT Message-ID: <6F406347BCC84ACBADFEFB8D805A04C6@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: Subject: Re: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Fri, 14 Nov 2008 11:34:09 -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, Some thoughts in addition to Attila's comments... === Abstract Can you please expand acronyms (as will be required by the RFC Ed.) I see... SONET SDH TDM ATM GMPLS === Main body of the document. Each acronym needs to be set out in full the first time it is used. I see... SONET SDH TDM ATM IEEE ITU MEF (transfer from later use) GMPLS VLAN (transfer from later use) === Please be consistent with the use of a space in either "IEEE 802" or "IEEE802" The space looks better to me. === Section 1 OLD procedures that will need to be changed is dependent NEW procedures that will need to be changed are dependent === Please be consistent "bidirectional" or "bi-directional" I prefer "bidirectional" and you only use "unidirectional" === Section 2.3.1 OLD o Asymmetric Bandwidth This term refers to the property of a Bi-directional LSP may have differing bandwidth allocation in each direction. NEW o Asymmetric Bandwidth This term refers to a property of a bidirectional LSP that may have differing bandwidth allocation in each direction. === Section 2.3.1 OLD o Bi-directional Congruent LSP This term refers to the property that an LSP shared the same nodes, ports and links. Ethernet data planes are normally bi- directional congruent. NEW o Bidirectional Congruent LSP This term refers to the property of a bidirectional LSP that uses only the same nodes, ports, and links in both directions. Ethernet data planes are normally bidirectional congruent. === Section 2.3.1 o Shared forwarding Shared forwarding is a property of a data path where a single forwarding entry (VID + DMAC) may be used for frames from multiple sources (SMAC). Shared forwarding does not change any data plane behavior it saves forwarding information base (FIB) entries only. From all other aspects it behaves as if there were multiple FIB entries. I don't understand the last sentence. Since there is only one FIB entry, the behavior cannot be as if there were multiple FIB entries. I suggest you either strike this sentence or add an example of what you mean. === Section 2.3.1 o Hierarchical Eth-LSP Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and tunneled, either individually or bundled, with other LSPs through a domain. I don't like this definition of hierarchical! Normally, we refer to the hierarchical LSP as the LSP that is the tunnel, not the LSP that is encapsulated. I think it would be helpful to remain consistent with RFC4206. === Section 2.4 etc. Please capitalise section headings === Section 2.4 Ethernet is similar to MPLS in that there is a default payload type. In MPLS, the default payload is either another MPLS label or an IP packet. The IP packet may carry any type of service IP carries. Ethernet assumes an Ethernet frame as the default payload. The actual service can be anything that Ethernet carries. I find this paragraph pretty weird! - What do you mean by a "default payload". Try telling the PWE3 working group that LSPs carry either another MPLS label or an IP packet! - How can "the default" payload be either one thing or another? - In what way does Ethernet assume that the default payload of Ethernet is also Ethernet? When would that assumption stop? It sounds arbitrarily recursive! It might help if you explained what value there is to knowing the default payload type. If there is no value *to* the*work*we*are*doing* in this document, then why bother mentioning it? === Section 2.4 Ethernet bridging is different from MPLS in that while the switching decision is taken on whatever is defined as the Ethernet label, that label is usually not swapped at each hop. "Usually"? Note that in MPLS you can use the same label on incoming and outgoing interfaces, but because the label could be swapped, we implement a swapping mechanism in all cases. Now, "usually" implies that sometimes the label may be swapped. This has significant implications for implementation. Perhaps you need to clarify this paragraph quite a bit. It might also help to discuss the context of the label. MPLS label contexts fall into three categories: - node - link - upstream neighbor What can you say about Ethernet? === Section 3 You list - priority level; - preemption characteristics; How are these different? === Section 3 Remove spare blank line between last 2 paras === Section 1 and Section 4.1 Please add a reference where you name LMP === Section 5 I think you should reference RFC3473 alongside RFC3471 === Section 5 OLD Signaling enables the ability to dynamically establish a path from one ingress or egress node. NEW Signaling enables the ability to dynamically establish a path from an ingress node to an egress node. === Section 5 Given this, Eth- LSPs MUST always use paths that share the same routes and fates. I believe you have defined a term specially for this? === Section 5 Eth- LSPs may be either P2P or P2MP (see [RFC4875]). You should probably add that only unidirectional P2MP Eth-LSPs are supported. === Section 5 Note that standard GMPLS does not support different bandwidth in each direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric bandwidth bidirectional LSPs are required. Suggest you change to Note that GMPLS as originally defined in [RFC3471] and [RFC3473] does not support... === Section 8 More detail will be added to the section in a later revision. You are running out of time :-) === Section 9 OLD the ports over which a UNI is defined is trusted NEW the ports over which a UNI are defined is trusted === Section 9 This section is a bit sparse. You should add a reference to draft-ietf-mpls-mpls-and-gmpls-security-framework (currently rev 04) You should describe why the change in data plane type does not impact the control plane security. You should mention the difference between in-band and out-of-band control planes in the Ethernet network since in this case, the data plane type does impact security. In particular, the in-band control plane can be used to attack the data plane capacity, and access to the data plane can be used to attack the control plane. === Thanks, Adrian PS. When you submit the updates, please use the new boilerplate and use idnits to verify everything. ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, October 29, 2008 7:47 PM Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt > 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 Fri Nov 14 03:51:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C873A6A6B for ; Fri, 14 Nov 2008 03:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 bFsrG5UxABGk for ; Fri, 14 Nov 2008 03:51:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74D4A3A6A69 for ; Fri, 14 Nov 2008 03:51:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0x9l-0008U4-W6 for ccamp-data@psg.com; Fri, 14 Nov 2008 11:48:09 +0000 Received: from [212.74.114.38] (helo=mk-outboundfilter-2.mail.uk.tiscali.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0x9f-0008Hj-LR for ccamp@ops.ietf.org; Fri, 14 Nov 2008 11:48:06 +0000 X-Trace: 160745557/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.113 X-SBRS: None X-RemoteIP: 62.188.105.113 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAHv0HEk+vGlx/2dsb2JhbABHgwqJW8MiB4Jx X-IronPort-AV: E=Sophos;i="4.33,602,1220223600"; d="scan'208";a="160745557" X-IP-Direction: IN Received: from 1cust113.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.113]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Nov 2008 11:47:59 +0000 Message-ID: <002601c94645$3f25cf20$0601a8c0@allison> Reply-To: "tom.petch" From: "tom.petch" To: "Adrian Farrel" , References: <002901c935f2$92f928d0$0200a8c0@your029b8cecfe> Subject: Re: A BNF specification for RSVP-GMPLS and LMP Date: Wed, 12 Nov 2008 18:42:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Adrian I have seen this announcement on a number of lists but I am unclear where you want the discussion to take place. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: Sent: Friday, October 24, 2008 5:05 PM Subject: A BNF specification for RSVP-GMPLS and LMP > 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 owner-ccamp@ops.ietf.org Fri Nov 14 04:04: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 EC5423A6A6E for ; Fri, 14 Nov 2008 04:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=-1.558, BAYES_40=-0.185, 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 4rdVS+NkpoQD for ; Fri, 14 Nov 2008 04:04:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21EAA3A6A60 for ; Fri, 14 Nov 2008 04:04:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0xMI-000AQa-86 for ccamp-data@psg.com; Fri, 14 Nov 2008 12:01:06 +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 1L0xMD-000AQC-3r for ccamp@ops.ietf.org; Fri, 14 Nov 2008 12:01:03 +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 mAEC0uJE027833; Fri, 14 Nov 2008 12:00:56 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 mAEC0tEh027797; Fri, 14 Nov 2008 12:00:55 GMT Message-ID: <0FE2923B03104207BBFBC2098F27399D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "tom.petch" , References: <002901c935f2$92f928d0$0200a8c0@your029b8cecfe> <002601c94645$3f25cf20$0601a8c0@allison> Subject: Re: A BNF specification for RSVP-GMPLS and LMP Date: Fri, 14 Nov 2008 12:00:50 -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: Tom, > I have seen this announcement on a number of lists but I am unclear where > you > want the discussion to take place. Anywhere :-) If you have issues specific to the use of the I-D in a particular set of documents for a protocol, take it to the list that owns that protocol. If you have issues related to the draft itself, take it to the routing discussion list (routing-discussion@ietf.org) Cheers, Adrian From owner-ccamp@ops.ietf.org Fri Nov 14 07:52:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B21F3A6A06 for ; Fri, 14 Nov 2008 07:52:15 -0800 (PST) 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 UyjXSLRsIvdi for ; Fri, 14 Nov 2008 07:52:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6374D3A6840 for ; Fri, 14 Nov 2008 07:52:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L10sU-000Nua-AP for ccamp-data@psg.com; Fri, 14 Nov 2008 15:46:34 +0000 Received: from [192.91.191.39] (helo=enfiets2.dataconnection.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L10sO-000Ntk-1i for ccamp@ops.ietf.org; Fri, 14 Nov 2008 15:46:31 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 14 Nov 2008 15:47:10 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Fri, 14 Nov 2008 15:46:25 +0000 From: Nic Neate To: labn - Lou Berger , "IBryskin@advaoptical.com" , ALU - Dimitri Papadimitriou , Aria - Adrian Farrel Personal CC: "ccamp@ops.ietf.org" Date: Fri, 14 Nov 2008 15:46:25 +0000 Subject: FW: Agenda updated Thread-Topic: Agenda updated Thread-Index: AclBEdrEXjU0mOCKQ3CvjSu7MB8uLADwUelg Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: RFC 4873 authors, Just wanted to flag that I'm presenting a problem in segment recovery signa= ling on Monday, together with a suggested solution. Problem statement: http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-si= gnaling-00. Suggested fix: http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-= fix-00. Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of Aria - Adrian Farrel Personal Sent: 07 November 2008 19:29 To: ccamp@ops.ietf.org Subject: Agenda updated I have made some updates. http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm Please shout if there further issues. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Nov 14 13:06:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E7A3A6907 for ; Fri, 14 Nov 2008 13:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=0.039, 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 1djTWgKZup1C for ; Fri, 14 Nov 2008 13:06:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92B243A68EC for ; Fri, 14 Nov 2008 13:06:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L15lN-000IIt-SI for ccamp-data@psg.com; Fri, 14 Nov 2008 20:59:33 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L15lI-000IIN-UK for ccamp@ops.ietf.org; Fri, 14 Nov 2008 20:59:31 +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 mAEKxNgX030079 for ; Fri, 14 Nov 2008 20:59:25 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 mAEKxMEq030065 for ; Fri, 14 Nov 2008 20:59:22 GMT Message-ID: <0CC568AD2A524BECA648AE622D9A8CB8@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: Subject: Last callcomplete : draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Fri, 14 Nov 2008 20:59:16 -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: Authors, You received some comments. Mainly editorial. The sooner you post a revision, the sooner it will go forward. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, October 29, 2008 7:47 PM Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt > 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 Sun Nov 16 05:50:48 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 934BC3A6AA6 for ; Sun, 16 Nov 2008 05:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[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 7g9maD6kz4uX for ; Sun, 16 Nov 2008 05:50:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 362A93A688B for ; Sun, 16 Nov 2008 05:50:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1huH-000D3n-Ob for ccamp-data@psg.com; Sun, 16 Nov 2008 13:43:17 +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 1L1huB-000D3E-8v for ccamp@ops.ietf.org; Sun, 16 Nov 2008 13:43: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 mAGDh5E8011495 for ; Sun, 16 Nov 2008 13:43:07 GMT Received: from your029b8cecfe ([12.104.246.2]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAGDgsrN011461 for ; Sun, 16 Nov 2008 13:43:02 GMT Message-ID: <10D6170A47D844D4B23F91AFB9C72D36@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Slides arriving and being posted Date: Sun, 16 Nov 2008 13:42:34 -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 to all that have sent slides already. Please check that they are correctly posted by visiting http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm We're still missing a few. Thanks, Adrian From owner-ccamp@ops.ietf.org Sun Nov 16 14:42: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 334713A68AF for ; Sun, 16 Nov 2008 14:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 ihZysVqbRatR for ; Sun, 16 Nov 2008 14:42:26 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA47C3A6358 for ; Sun, 16 Nov 2008 14:42:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1qF4-000Gr0-4e for ccamp-data@psg.com; Sun, 16 Nov 2008 22:37:18 +0000 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1qEy-000GqN-QV for ccamp@ops.ietf.org; Sun, 16 Nov 2008 22:37:15 +0000 Received: from FRVELSBHS06.ad2.ad.alcatel.com ([155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mAGMaxar021955; Sun, 16 Nov 2008 23:36:59 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 16 Nov 2008 23:36:59 +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: Agenda updated Date: Sun, 16 Nov 2008 23:36:59 +0100 Message-ID: <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda updated Thread-Index: AclBEdrEXjU0mOCKQ3CvjSu7MB8uLADwUelgANoLACA= References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , "labn - Lou Berger" , , "Aria - Adrian Farrel Personal" Cc: X-OriginalArrivalTime: 16 Nov 2008 22:36:59.0041 (UTC) FILETIME=[D62E7910:01C9483B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: nick, you mention: "3.1 Association between LSPs in different sessions Segment recovery protecting LSPs may have a different endpoint address from the corresponding protected LSP. The protected and protecting LSPs are therefore in different Sessions. The Association object of type 1 (recovery) is not effective in this case, as the Association ID can only associate to an LSP ID within the same Session." but segment recovery makes use of: "9.1. New Association Type Assignment IANA has made the following assignment to the "Association Types" Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. Value Type ----- ---- 2 Resource Sharing (R) [RFC4873]"=20 and states: "Consider the following topology: A---B---C---D---E---F \ / G---I In this topology, end-to-end protection and recovery is not possible for an LSP going between node A and node F, but it is possible to protect/recover a portion of the LSP. Specifically, if the LSP uses a working path of [A,B,C,D,E,F], then a protection or restoration LSP can be established along the path [C,G,I,E]."=20 [...] "Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path, e.g., node E shown above. There is no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID." so where is the issue ? -d. > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Friday, November 14, 2008 4:46 PM > To: labn - Lou Berger; IBryskin@advaoptical.com;=20 > PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal > Cc: ccamp@ops.ietf.org > Subject: FW: Agenda updated >=20 > RFC 4873 authors, >=20 > Just wanted to flag that I'm presenting a problem in segment=20 > recovery signaling on Monday, together with a suggested solution. >=20 > Problem statement:=20 > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > Suggested fix:=20 > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. >=20 >=20 > Nic >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian=20 > Farrel Personal > Sent: 07 November 2008 19:29 > To: ccamp@ops.ietf.org > Subject: Agenda updated >=20 > I have made some updates. >=20 > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm >=20 > Please shout if there further issues. >=20 > Thanks, > Adrian >=20 >=20 From owner-ccamp@ops.ietf.org Sun Nov 16 14:50:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A2A3A68B8 for ; Sun, 16 Nov 2008 14:50:07 -0800 (PST) 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 3lGR0EUwe0Jq for ; Sun, 16 Nov 2008 14:50:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 925B83A69CF for ; Sun, 16 Nov 2008 14:50:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1qNx-000HNr-3l for ccamp-data@psg.com; Sun, 16 Nov 2008 22:46:29 +0000 Received: from [67.222.38.37] (helo=outbound-mail-147.bluehost.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1qNs-000HNT-5C for ccamp@ops.ietf.org; Sun, 16 Nov 2008 22:46:26 +0000 Received: (qmail 24874 invoked by uid 0); 16 Nov 2008 22:46:23 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy5.bluehost.com with SMTP; 16 Nov 2008 22:46:23 -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=XOx9LiFUHqi7Oz0/fidAK2+gB+hWspgL37r1XKeBJ+GI4/3pDDGWwUvn3XCCvQd80/0XmxvhAyxIMw2neLj5/b6La8/PIqytY2fSgVnmbNtyEQdI0XeRTRaC1Ab0SQZ8; 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 1L1qNP-0004qt-HP; Sun, 16 Nov 2008 15:45:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Nov 2008 17:45:57 -0500 To: "Nic Neate" From: Lou Berger Subject: RE: Agenda updated Cc: "Lou Berger" ,, ,, "PAPADIMITRIOU Dimitri" In-Reply-To: <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.a d.alcatel.com> References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> 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: I agree with Dimitri. also, note: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Lou At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: >nick, > >you mention: > >"3.1 Association between LSPs in different sessions > > Segment recovery protecting LSPs may have a different endpoint > address from the corresponding protected LSP. The protected and > protecting LSPs are therefore in different Sessions. The Association > object of type 1 (recovery) is not effective in this case, as the > Association ID can only associate to an LSP ID within the same > Session." > >but segment recovery makes use of: > >"9.1. New Association Type Assignment > > > IANA has made the following assignment to the "Association Types" > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > "RSVP PARAMETERS" registry located at > http://www.iana.org/assignments/rsvp-parameters. > > Value Type > ----- ---- > 2 Resource Sharing (R) [RFC4873]" > >and states: > >"Consider the following topology: > > A---B---C---D---E---F > \ / > G---I > > In this topology, end-to-end protection and recovery is not possible > for an LSP going between node A and node F, but it is possible to > protect/recover a portion of the LSP. Specifically, if the LSP uses > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > can be established along the path [C,G,I,E]." > >[...] > >"Segment protection or restoration is signaled using a working LSP and > one or more segment recovery LSPs. Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path, > e.g., node E shown above. There is no specific requirement on LSP ID > value, Tunnel ID, and Extended Tunnel ID." > >so where is the issue ? > >-d. > > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, November 14, 2008 4:46 PM > > To: labn - Lou Berger; IBryskin@advaoptical.com; > > PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal > > Cc: ccamp@ops.ietf.org > > Subject: FW: Agenda updated > > > > RFC 4873 authors, > > > > Just wanted to flag that I'm presenting a problem in segment > > recovery signaling on Monday, together with a suggested solution. > > > > Problem statement: > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > Suggested fix: > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > Nic > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian > > Farrel Personal > > Sent: 07 November 2008 19:29 > > To: ccamp@ops.ietf.org > > Subject: Agenda updated > > > > I have made some updates. > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > Please shout if there further issues. > > > > Thanks, > > Adrian > > > > From owner-ccamp@ops.ietf.org Sun Nov 16 14:51: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 F06903A686C for ; Sun, 16 Nov 2008 14:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 cgxIVFfeDTzT for ; Sun, 16 Nov 2008 14:51:55 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 241E33A6358 for ; Sun, 16 Nov 2008 14:51:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1qQR-000HZO-NZ for ccamp-data@psg.com; Sun, 16 Nov 2008 22:49:03 +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 1L1qQL-000HYn-Mq for ccamp@ops.ietf.org; Sun, 16 Nov 2008 22:48:59 +0000 Received: from FRVELSBHS05.ad2.ad.alcatel.com ([155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mAGMmtwE009833; Sun, 16 Nov 2008 23:48:55 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 16 Nov 2008 23:48:55 +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: Slides arriving and being posted Date: Sun, 16 Nov 2008 23:48:55 +0100 Message-ID: <00275A5B436CA441900CB10936742A38015CD738@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <10D6170A47D844D4B23F91AFB9C72D36@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides arriving and being posted Thread-Index: AclH8aWFOOOek7QhSt2A+L8D6SkHTwAS5hTw References: <10D6170A47D844D4B23F91AFB9C72D36@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 16 Nov 2008 22:48:55.0353 (UTC) FILETIME=[81230290:01C9483D] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: =20 adrian - looking at your slides and except if i missed it the doc the new release includes clarification on index field encoding. so except if there is any remaining issue from known implementations this doc is also ready for WG LC.=20 thx, -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, November 16, 2008 2:43 PM > To: ccamp@ops.ietf.org > Subject: Slides arriving and being posted >=20 > Hi, >=20 > Thanks to all that have sent slides already. >=20 > Please check that they are correctly posted by visiting=20 > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm >=20 > We're still missing a few. >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Sun Nov 16 15:13:17 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D393A69B7 for ; Sun, 16 Nov 2008 15:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 FF3ZwVLaK-hz for ; Sun, 16 Nov 2008 15:13:16 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F33A3A6358 for ; Sun, 16 Nov 2008 15:13:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1qkL-000Ius-Rn for ccamp-data@psg.com; Sun, 16 Nov 2008 23:09:37 +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 1L1qk7-000ItN-Bg for ccamp@ops.ietf.org; Sun, 16 Nov 2008 23:09:34 +0000 Received: from FRVELSBHS02.ad2.ad.alcatel.com ([155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mAGN9Kdb023626; Mon, 17 Nov 2008 00:09:20 +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); Mon, 17 Nov 2008 00:09:20 +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: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Mon, 17 Nov 2008 00:09:21 +0100 Message-ID: <00275A5B436CA441900CB10936742A38015CD739@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <6F406347BCC84ACBADFEFB8D805A04C6@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Thread-Index: AclGTUfGUC6gzat4SNynBlKXbv1N/QB8IvMA References: <6F406347BCC84ACBADFEFB8D805A04C6@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 16 Nov 2008 23:09:20.0394 (UTC) FILETIME=[5B516EA0:01C94840] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: hi adrian reading this doc. the section 2 2 Background ................................................ 5 2.1 Ethernet Switching ........................................ 5 2.2 Operations, Administration, and Maintenance (OAM) ......... 7 2.3 Terminology ............................................... 8 2.3.1 Concepts .................................................. 8 2.3.2 Abbreviations and Acronyms ................................ 9 2.4 Ethernet and MPLS similarities and differences ............ 10 as it names indicates provides Ethernet background info while i thought the doc. was meant to deal with protocol architecture issues. of course there is a relationship but these sections should better be included in an appendix or so. The sentence "Ethernet is similar to MPLS in that there is a default payload type." i missed the def. of a payload type in RFC3031. Section 2.3 should also be made separate from this background information on Ethernet techno itself.=20 Section 6 reads as a recommendation on protocol usage not on architecture e.g. "It is RECOMMENDED that LMP not be used for Fault management and instead the native Ethernet methods be used." I am not sure to see why an IETF document shall preclude usage of its own protocols except if there is a good reason for (use of LMP on shared medium is tedious since on CC shall be setup between each node). Other comments: " Extensions to support non-IP based LSP identification in signaling, i.e., replacement of the IP address in the RSVP SESSION or SENDER_TSPEC objects, are not permitted under this framework." -> Well i would phrase this in the other way around "Support of Ethernet MUST strictly comply to the GMPLS protocol suite addressing as specific in RFC3471, RFC3473 and related." "This document allows for the support the signaling of Ethernet parameters across multiple domains" -> How do you define the term domain in the present context ? is it related to the Ethernet partitioning and/or segmentation in client/provider MAC address space ? thanks, -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, November 14, 2008 12:34 PM > To: ccamp@ops.ietf.org > Subject: Re: Two week last call on=20 > draft-ietf-ccamp-gmpls-ethernet-arch-03.txt >=20 > Hi, >=20 > Some thoughts in addition to Attila's comments... >=20 > =3D=3D=3D > Abstract > Can you please expand acronyms (as will be required by the RFC Ed.) > I see... > SONET > SDH > TDM > ATM > GMPLS > =3D=3D=3D > Main body of the document. > Each acronym needs to be set out in full the first time it is used. > I see... > SONET > SDH > TDM > ATM > IEEE > ITU > MEF (transfer from later use) > GMPLS > VLAN (transfer from later use) > =3D=3D=3D > Please be consistent with the use of a space in either "IEEE 802" or=20 > "IEEE802" > The space looks better to me. > =3D=3D=3D > Section 1 > OLD > procedures that will need to be changed is dependent > NEW > procedures that will need to be changed are dependent > =3D=3D=3D > Please be consistent "bidirectional" or "bi-directional" > I prefer "bidirectional" and you only use "unidirectional" > =3D=3D=3D > Section 2.3.1 > OLD > o Asymmetric Bandwidth >=20 > This term refers to the property of a Bi-directional=20 > LSP may have > differing bandwidth allocation in each direction. > NEW > o Asymmetric Bandwidth >=20 > This term refers to a property of a bidirectional LSP=20 > that may have > differing bandwidth allocation in each direction. > =3D=3D=3D > Section 2.3.1 > OLD > o Bi-directional Congruent LSP >=20 > This term refers to the property that an LSP shared the same > nodes, ports and links. Ethernet data planes are normally bi- > directional congruent. > NEW > o Bidirectional Congruent LSP >=20 > This term refers to the property of a bidirectional=20 > LSP that uses > only the same nodes, ports, and links in both=20 > directions. Ethernet > data planes are normally bidirectional congruent. > =3D=3D=3D > Section 2.3.1 >=20 > o Shared forwarding >=20 > Shared forwarding is a property of a data path where a single > forwarding entry (VID + DMAC) may be used for frames from > multiple sources (SMAC). Shared forwarding does not change any > data plane behavior it saves forwarding information base (FIB) > entries only. From all other aspects it behaves as if=20 > there were > multiple FIB entries. >=20 > I don't understand the last sentence. Since there is only one=20 > FIB entry, the=20 > behavior cannot be as if there were multiple FIB entries. I=20 > suggest you=20 > either strike this sentence or add an example of what you mean. > =3D=3D=3D > Section 2.3.1 > o Hierarchical Eth-LSP >=20 > Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and > tunneled, either individually or bundled, with other=20 > LSPs through > a domain. >=20 > I don't like this definition of hierarchical! Normally, we=20 > refer to the=20 > hierarchical LSP as the LSP that is the tunnel, not the LSP that is=20 > encapsulated. I think it would be helpful to remain=20 > consistent with RFC4206. > =3D=3D=3D > Section 2.4 etc. > Please capitalise section headings > =3D=3D=3D > Section 2.4 > Ethernet is similar to MPLS in that there is a default=20 > payload type. > In MPLS, the default payload is either another MPLS label or an IP > packet. The IP packet may carry any type of service IP carries. > Ethernet assumes an Ethernet frame as the default payload.=20 > The actual > service can be anything that Ethernet carries. >=20 > I find this paragraph pretty weird! > - What do you mean by a "default payload". Try telling the PWE3 > working group that LSPs carry either another MPLS label or an > IP packet! > - How can "the default" payload be either one thing or another? > - In what way does Ethernet assume that the default payload of > Ethernet is also Ethernet? When would that assumption stop? > It sounds arbitrarily recursive! > It might help if you explained what value there is to knowing=20 > the default=20 > payload type. If there is no value *to*=20 > the*work*we*are*doing* in this=20 > document, then why bother mentioning it? > =3D=3D=3D > Section 2.4 > Ethernet bridging is different from MPLS in that while the=20 > switching > decision is taken on whatever is defined as the Ethernet=20 > label, that > label is usually not swapped at each hop. >=20 > "Usually"? > Note that in MPLS you can use the same label on incoming and outgoing=20 > interfaces, but because the label could be swapped, we=20 > implement a swapping=20 > mechanism in all cases. > Now, "usually" implies that sometimes the label may be=20 > swapped. This has=20 > significant implications for implementation. >=20 > Perhaps you need to clarify this paragraph quite a bit. It=20 > might also help=20 > to discuss the context of the label. MPLS label contexts fall=20 > into three=20 > categories: > - node > - link > - upstream neighbor > What can you say about Ethernet? > =3D=3D=3D > Section 3 > You list > - priority level; > - preemption characteristics; > How are these different? > =3D=3D=3D > Section 3 > Remove spare blank line between last 2 paras > =3D=3D=3D > Section 1 and Section 4.1 > Please add a reference where you name LMP > =3D=3D=3D > Section 5 > I think you should reference RFC3473 alongside RFC3471 > =3D=3D=3D > Section 5 > OLD > Signaling enables the ability to > dynamically establish a path from one ingress or egress node. > NEW > Signaling enables the ability to > dynamically establish a path from an ingress node to an > egress node. > =3D=3D=3D > Section 5 > Given this, Eth- > LSPs MUST always use paths that share the same routes and fates. > I believe you have defined a term specially for this? > =3D=3D=3D > Section 5 > Eth- > LSPs may be either P2P or P2MP (see [RFC4875]). > You should probably add that only unidirectional P2MP Eth-LSPs are=20 > supported. > =3D=3D=3D > Section 5 > Note that standard GMPLS does not support different=20 > bandwidth in each > direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric > bandwidth bidirectional LSPs are required. > Suggest you change to > Note that GMPLS as originally defined in [RFC3471] and=20 > [RFC3473] does > not support... > =3D=3D=3D > Section 8 > More detail will be added to the section in a later revision. > You are running out of time :-) > =3D=3D=3D > Section 9 > OLD > the ports over which a UNI is defined is trusted > NEW > the ports over which a UNI are defined is trusted > =3D=3D=3D > Section 9 > This section is a bit sparse. > You should add a reference to=20 > draft-ietf-mpls-mpls-and-gmpls-security-framework (currently rev 04) > You should describe why the change in data plane type does=20 > not impact the=20 > control plane security. > You should mention the difference between in-band and=20 > out-of-band control=20 > planes in the Ethernet network since in this case, the data=20 > plane type does=20 > impact security. In particular, the in-band control plane can=20 > be used to=20 > attack the data plane capacity, and access to the data plane=20 > can be used to=20 > attack the control plane. > =3D=3D=3D >=20 > Thanks, > Adrian >=20 > PS. When you submit the updates, please use the new=20 > boilerplate and use=20 > idnits to verify everything. >=20 > ----- Original Message -----=20 > From: "Adrian Farrel" > To: > Sent: Wednesday, October 29, 2008 7:47 PM > Subject: Two week last call on=20 > draft-ietf-ccamp-gmpls-ethernet-arch-03.txt >=20 >=20 > > This email starts a two week working group last call on=20 > "GMPLS Ethernet=20 > > Label Switching Architecture and Framework" > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth > ernet-arch-03.txt > > > > The I-D is marked as Informational. > > > > Please send your comments to the list by 12 noon GMT Friday=20 > 14th November. > > > > Thanks, > > Adrian and Deborah > > > >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Sun Nov 16 16:37:56 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 5670C3A67AA for ; Sun, 16 Nov 2008 16:37:56 -0800 (PST) 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 0-WWNXrUsLtK for ; Sun, 16 Nov 2008 16:37:55 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55AD93A6358 for ; Sun, 16 Nov 2008 16:37:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1s3E-000Nzx-UR for ccamp-data@psg.com; Mon, 17 Nov 2008 00:33:12 +0000 Received: from [192.91.191.38] (helo=enfiets1.dataconnection.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1s39-000Nzg-Fq for ccamp@ops.ietf.org; Mon, 17 Nov 2008 00:33:10 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 17 Nov 2008 00:33:22 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Mon, 17 Nov 2008 00:33:02 +0000 From: Nic Neate To: labn - Lou Berger , ALU - Dimitri Papadimitriou CC: "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" Date: Mon, 17 Nov 2008 00:32:57 +0000 Subject: RE: Agenda updated Thread-Topic: Agenda updated Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAADXPIg Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4018DF@ENFIMBOX1.ad.datcon.co.uk> References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Lou, Dimitri, I agree that association type 2, "Resource Sharing", allows LSPs in differe= nt session to be associated. However, RFC 4873 defines its use as being for make-before-break of segment= recovery LSPs, not for associating the recovery LSP with the protected LSP= . See section 3.2.2: 3.2.2. Resource Sharing Association Type Processing The ASSOCIATION object with an Association Type with the value Resource Sharing is used to enable resource sharing during make- before-break. Resource sharing during make-before-break is defined in [RFC3209]. The defined support only works with LSPs that share the same LSP egress. With the introduction of segment recovery LSPs, it is now possible for an LSP endpoint to change during make-before- break. Association type 1, from RFC 4873, is still used to associate the segment r= ecovery LSP with the protected LSP. Hence the problem described in our dra= ft. Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of labn - Lou Berger Sent: 16 November 2008 22:46 To: Nic Neate Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Perso= nal; ccamp@ops.ietf.org; ALU - Dimitri Papadimitriou Subject: RE: Agenda updated I agree with Dimitri. also, note: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Lou At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: >nick, > >you mention: > >"3.1 Association between LSPs in different sessions > > Segment recovery protecting LSPs may have a different endpoint > address from the corresponding protected LSP. The protected and > protecting LSPs are therefore in different Sessions. The Association > object of type 1 (recovery) is not effective in this case, as the > Association ID can only associate to an LSP ID within the same > Session." > >but segment recovery makes use of: > >"9.1. New Association Type Assignment > > > IANA has made the following assignment to the "Association Types" > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > "RSVP PARAMETERS" registry located at > http://www.iana.org/assignments/rsvp-parameters. > > Value Type > ----- ---- > 2 Resource Sharing (R) [RFC4873]" > >and states: > >"Consider the following topology: > > A---B---C---D---E---F > \ / > G---I > > In this topology, end-to-end protection and recovery is not possible > for an LSP going between node A and node F, but it is possible to > protect/recover a portion of the LSP. Specifically, if the LSP uses > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > can be established along the path [C,G,I,E]." > >[...] > >"Segment protection or restoration is signaled using a working LSP and > one or more segment recovery LSPs. Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path, > e.g., node E shown above. There is no specific requirement on LSP ID > value, Tunnel ID, and Extended Tunnel ID." > >so where is the issue ? > >-d. > > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, November 14, 2008 4:46 PM > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > Dimitri; Aria - Adrian Farrel Personal > > Cc: ccamp@ops.ietf.org > > Subject: FW: Agenda updated > > > > RFC 4873 authors, > > > > Just wanted to flag that I'm presenting a problem in segment > > recovery signaling on Monday, together with a suggested solution. > > > > Problem statement: > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > Suggested fix: > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > Nic > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian Farrel > > Personal > > Sent: 07 November 2008 19:29 > > To: ccamp@ops.ietf.org > > Subject: Agenda updated > > > > I have made some updates. > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > Please shout if there further issues. > > > > Thanks, > > Adrian > > > > From owner-ccamp@ops.ietf.org Sun Nov 16 19:15: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 BCB8028C0EC for ; Sun, 16 Nov 2008 19:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Mrp7H4XDqmwT for ; Sun, 16 Nov 2008 19:15:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4EB9428C0DB for ; Sun, 16 Nov 2008 19:15:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1uUa-0006Q0-Tr for ccamp-data@psg.com; Mon, 17 Nov 2008 03:09:36 +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 1L1uUV-0006PL-5O for ccamp@ops.ietf.org; Mon, 17 Nov 2008 03:09:33 +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 mAH39PTd014198 for ; Mon, 17 Nov 2008 03:09:27 GMT Received: from your029b8cecfe ([12.104.246.2]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAH39M6v014151 for ; Mon, 17 Nov 2008 03:09:24 GMT Message-ID: <7463A5AFD3FF4622A0296F8EFC5A3855@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Last Call: draft-dasgupta-ccamp-path-comp-analysis (Performance Analysis of Inter-Domain Path Computation Methodologies) to Informational RFC Date: Mon, 17 Nov 2008 03:09:09 -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: Heads up! ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Sent: Sunday, November 16, 2008 10:54 PM Subject: Last Call: draft-dasgupta-ccamp-path-comp-analysis (Performance Analysis of Inter-Domain Path Computation Methodologies) to Informational RFC > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Performance Analysis of Inter-Domain Path Computation Methodologies ' > as an Informational 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-12-14. 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-dasgupta-ccamp-path-comp-analysis-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16050&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From owner-ccamp@ops.ietf.org Sun Nov 16 19:17: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 E7E2E3A6804 for ; Sun, 16 Nov 2008 19:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.083, 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 FbnwY4aboHYt for ; Sun, 16 Nov 2008 19:17:54 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 42E933A67BD for ; Sun, 16 Nov 2008 19:17:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L1uZe-0006mF-64 for ccamp-data@psg.com; Mon, 17 Nov 2008 03:14:50 +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 1L1uZT-0006jh-HF for ccamp@ops.ietf.org; Mon, 17 Nov 2008 03:14:46 +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 mAH3EZ7P015019; Mon, 17 Nov 2008 03:14:35 GMT Received: from your029b8cecfe ([12.104.246.2]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAH3EW95015012; Mon, 17 Nov 2008 03:14:34 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , References: <10D6170A47D844D4B23F91AFB9C72D36@your029b8cecfe> <00275A5B436CA441900CB10936742A38015CD738@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: Slides arriving and being posted Date: Mon, 17 Nov 2008 03:13:23 -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: You are right, I missed this off the list. It will be there before Monday afternoon. A ----- Original Message ----- From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" ; Sent: Sunday, November 16, 2008 10:48 PM Subject: RE: Slides arriving and being posted adrian - looking at your slides and except if i missed it the doc the new release includes clarification on index field encoding. so except if there is any remaining issue from known implementations this doc is also ready for WG LC. thx, -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, November 16, 2008 2:43 PM > To: ccamp@ops.ietf.org > Subject: Slides arriving and being posted > > Hi, > > Thanks to all that have sent slides already. > > Please check that they are correctly posted by visiting > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > We're still missing a few. > > Thanks, > Adrian > > > From owner-ccamp@ops.ietf.org Mon Nov 17 05:13: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 61EB13A686E for ; Mon, 17 Nov 2008 05:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.591 X-Spam-Level: X-Spam-Status: No, score=0.591 tagged_above=-999 required=5 tests=[AWL=-0.774, 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 5t2FjCxkleux for ; Mon, 17 Nov 2008 05:13:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 068F33A6403 for ; Mon, 17 Nov 2008 05:13:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L23pp-000EMI-2O for ccamp-data@psg.com; Mon, 17 Nov 2008 13:08:09 +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 1L23pk-000ELs-Ah for ccamp@ops.ietf.org; Mon, 17 Nov 2008 13:08:06 +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 mAHD7xXg014085 for ; Mon, 17 Nov 2008 13:08:00 GMT Received: from your029b8cecfe ([130.129.79.220]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAHD7vS4014045 for ; Mon, 17 Nov 2008 13:07:59 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Wondering about the new boiler plate? Date: Mon, 17 Nov 2008 13:06:19 -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: Were you wondering how to get the new boiler plate text right in your draft submissions? You may find it easiest to crib from an existing draft by stealing the top and tail. I think you will find it right in http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-04.txt Cheers, Adrian From owner-ccamp@ops.ietf.org Mon Nov 17 07:49: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 8C5E83A6808 for ; Mon, 17 Nov 2008 07:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 vVlFYQSTtc4w for ; Mon, 17 Nov 2008 07:49:58 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC8EE3A67A6 for ; Mon, 17 Nov 2008 07:49:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L26IC-000OTH-Ri for ccamp-data@psg.com; Mon, 17 Nov 2008 15:45:36 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L26I7-000OSs-SZ for ccamp@ops.ietf.org; Mon, 17 Nov 2008 15:45:34 +0000 Received: from [172.17.196.165] ([12.167.162.5]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id mAHFjSSd058774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Nov 2008 07:45:30 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4921919A.1020707@grotto-networking.com> Date: Mon, 17 Nov 2008 09:45:30 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp Subject: Informal WSON discussion meeting... Content-Type: multipart/alternative; boundary="------------050503050002070708070803" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------050503050002070708070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton). Discussion Topics may include: (a) WSON Framework and RWA Information model document contents and structure * (b) Wavelength converter pool model for use in path computation (c) Signaling extensions -- other uses of wavelength set metric (d) Optical Impairments and the control plane * It is assumed that everyone attending will have *read all the related drafts*. Also this discussion section probably isn't recommended for "tourists". Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050503050002070708070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:
(a) WSON Framework and RWA Information model document contents and structure *
(b) Wavelength converter pool model for use in path computation
(c) Signaling extensions -- other uses of wavelength set metric
(d) Optical Impairments and the control plane  *

It is assumed that everyone attending will have read all the related drafts. Also this discussion section probably isn't recommended for "tourists".

Regards

Greg
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050503050002070708070803-- From owner-ccamp@ops.ietf.org Mon Nov 17 07:50:17 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687CD3A6808 for ; Mon, 17 Nov 2008 07:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 EJknT-xIKLQ3 for ; Mon, 17 Nov 2008 07:50:16 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 956843A67A6 for ; Mon, 17 Nov 2008 07:50:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L26Hr-000OS7-9G for ccamp-data@psg.com; Mon, 17 Nov 2008 15:45:15 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L26Hl-000ORn-Gn for ccamp@ops.ietf.org; Mon, 17 Nov 2008 15:45:11 +0000 Received: from [172.17.196.165] ([12.167.162.5]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id mAHFj5iO058357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Nov 2008 07:45:07 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <49219183.5010707@grotto-networking.com> Date: Mon, 17 Nov 2008 09:45:07 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp Subject: Informal WSON discussion meeting... Content-Type: multipart/alternative; boundary="------------000507000806090106010203" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------000507000806090106010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton). Discussion Topics may include: (a) WSON Framework and RWA Information model document contents and structure * (b) Wavelength converter pool model for use in path computation (c) Signaling extensions -- other uses of wavelength set metric (d) Optical Impairments and the control plane * It is assumed that everyone attending will have *read all the related drafts*. Also this discussion section probably isn't recommended for "tourists". Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------000507000806090106010203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:
(a) WSON Framework and RWA Information model document contents and structure *
(b) Wavelength converter pool model for use in path computation
(c) Signaling extensions -- other uses of wavelength set metric
(d) Optical Impairments and the control plane  *

It is assumed that everyone attending will have read all the related drafts. Also this discussion section probably isn't recommended for "tourists".

Regards

Greg
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------000507000806090106010203-- From dvd07102008@gmail.com Mon Nov 17 08:16:23 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 35B3A28C17A for ; Mon, 17 Nov 2008 08:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.6 X-Spam-Level: **** X-Spam-Status: No, score=4.6 tagged_above=-999 required=5 tests=[AWL=0.022, 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 U1HKcjJ8byO3 for ; Mon, 17 Nov 2008 08:16:22 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 3290D3A6A3D for ; Mon, 17 Nov 2008 08:16:12 -0800 (PST) Received: from localhost ([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 <0KAH0049VJUHW600@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Mon, 17 Nov 2008 13:15:57 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Mon, 17 Nov 2008 14:15:53 +0100 Date: Mon, 17 Nov 2008 14:15:54 +0100 From: "dvd07102008@gmail.com" Subject: SOLO POR HOY To: solo por hoy Errors-to: dvd07102008_@gmail.com Message-id: <381-2200811117131554125@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: n06112008@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: $3500 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: $3500 From owner-ccamp@ops.ietf.org Mon Nov 17 11:34: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 F21B03A6A13 for ; Mon, 17 Nov 2008 11:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.441 X-Spam-Level: X-Spam-Status: No, score=-101.441 tagged_above=-999 required=5 tests=[AWL=1.159, 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 qq6hbKX2YB5z for ; Mon, 17 Nov 2008 11:34:36 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F6453A69D8 for ; Mon, 17 Nov 2008 11:34:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L29nU-000E1d-Dg for ccamp-data@psg.com; Mon, 17 Nov 2008 19:30: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 1L29nO-000E1A-Em for ccamp@ops.ietf.org; Mon, 17 Nov 2008 19:30:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A7C2B3A6A1F; Mon, 17 Nov 2008 11:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081117193001.A7C2B3A6A1F@core3.amsl.com> Date: Mon, 17 Nov 2008 11:30:01 -0800 (PST) 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 Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt Pages : 15 Date : 2008-11-17 This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-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-asymm-bw-bidir-lsps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-17111812.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Nov 17 14:27:09 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D53428C15B for ; Mon, 17 Nov 2008 14:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.255, 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 ogiDHuhTDVSu for ; Mon, 17 Nov 2008 14:27:08 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 540F028C15F for ; Mon, 17 Nov 2008 14:27:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2CUu-000P1h-S5 for ccamp-data@psg.com; Mon, 17 Nov 2008 22:23:08 +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 1L2CUi-000P10-6l for ccamp@ops.ietf.org; Mon, 17 Nov 2008 22:22:58 +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 mAHMMQE4021678; Mon, 17 Nov 2008 22:22:26 GMT Received: from your029b8cecfe ([130.129.94.211]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAHMMNp8021667; Mon, 17 Nov 2008 22:22:25 GMT Message-ID: <79713195F7CF4AF99120D6E9672D586F@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Michael H. Behringer" , "Francois Le Faucheur" Subject: Soliciting feedback ondraft-ietf-tsvwg-rsvp-security-groupkeying Date: Mon, 17 Nov 2008 22:22:19 -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 CCAMP, The TSVWG is doing work on group keys for RSVP. These might also be applicable to GMPLS/RSVP-TE so please review the draft (specifically section 5) and send comments to the author (Michael Behringer ) and to the CCAMP list (and preferably the TSVWG list as well). http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/ Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Nov 18 05:04:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B34D3A68FD for ; Tue, 18 Nov 2008 05:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[AWL=-1.504, 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 aAEaeCW3U4Yi for ; Tue, 18 Nov 2008 05:04:25 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BE183A67ED for ; Tue, 18 Nov 2008 05:04:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2QA2-000F9E-2T for ccamp-data@psg.com; Tue, 18 Nov 2008 12:58: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 1L2Q9x-000F8r-MD for ccamp@ops.ietf.org; Tue, 18 Nov 2008 12:58: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 mAICwLAj018403 for ; Tue, 18 Nov 2008 12:58:22 GMT Received: from your029b8cecfe ([130.129.79.220]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAICwJ2f018375 for ; Tue, 18 Nov 2008 12:58:20 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Did anyone listen to CCAMP on audio streaming? Date: Tue, 18 Nov 2008 12:58:13 -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: Can you drop me an email so we can find out how it sounded. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Nov 18 06:05:23 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 E05F33A67E2 for ; Tue, 18 Nov 2008 06:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=0.047, 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 9CQWEJG9RsTA for ; Tue, 18 Nov 2008 06:05:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F0A923A679C for ; Tue, 18 Nov 2008 06:05:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2R7j-000IBK-SS for ccamp-data@psg.com; Tue, 18 Nov 2008 14:00:11 +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 1L2R7e-000IAl-H6 for ccamp@ops.ietf.org; Tue, 18 Nov 2008 14:00:08 +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 mAIE025S013716; Tue, 18 Nov 2008 14:00:02 GMT Received: from your029b8cecfe ([130.129.79.220]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAIE00iA013656; Tue, 18 Nov 2008 14:00:01 GMT Message-ID: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Nic Neate" Cc: Subject: Clearing up your misunderstanding of the Association ID Date: Tue, 18 Nov 2008 13:59:56 -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 Nic, I think there are a bunch of issues that you are raising, and we should try to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think you may have misread the relevant RFCs. I don't believe any new Association ID type is needed to achieve the function: we can simply use the 4872 association type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that in 4873, the context is not end-to-end LSP recovery so the restriction on the Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of your issues go away. Cheers, Adrian From owner-ccamp@ops.ietf.org Tue Nov 18 06:12: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 AB09B3A679C for ; Tue, 18 Nov 2008 06:12:05 -0800 (PST) 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 ZfJ99khXs+Ll for ; Tue, 18 Nov 2008 06:12:04 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ABF13A6784 for ; Tue, 18 Nov 2008 06:12:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2RE5-000IYd-PH for ccamp-data@psg.com; Tue, 18 Nov 2008 14:06:45 +0000 Received: from [192.91.191.38] (helo=enfiets1.dataconnection.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2RDy-000IY7-NU for ccamp@ops.ietf.org; Tue, 18 Nov 2008 14:06:42 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 18 Nov 2008 14:06:58 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Tue, 18 Nov 2008 14:06:39 +0000 From: Nic Neate To: labn - Lou Berger CC: "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" , ALU - Dimitri Papadimitriou Date: Tue, 18 Nov 2008 14:06:34 +0000 Subject: RE: Agenda updated Thread-Topic: Agenda updated Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAA3sOeA Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.datcon.co.uk> References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Lou, Following up on our conversation in CCAMP. I think you agreed that the "Resource Sharing" association type 2 is not re= levant to this discussion. You also said that the intent of the statement from 3.2.1 "processing and i= dentification occur with respect to segment recovery LSPs" is to indicate t= hat the procedures defined in RFC 4872 for setting the association ID to an= LSP ID are not used. Instead, a unique identifier should be chosen by the= association source (as suggested in our draft). I find this quite a stretch, and think a clarification would improve the ch= ances of interoperability. I'm also concerned with the reuse of association type 1 with different sema= ntics in segment recovery to those defined for end-to-end recovery. Consid= er the case where a segment recovery LSP is itself end-to-end protected. T= hen there will be two type 1 association objects, and the merge node must p= rocess each differently. How does the implementation you mentioned decide = which is which? You also dismissed the other issues raised in draft-rhodes-rsvp-recovery-si= gnaling relating to protection of recovery LSPs and overlaping protection. = Please could you respond on the specific technical points raised in the dr= aft? I'd be glad to meet up and discuss this in person while we're in Minneapoli= s. Thanks, Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of labn - Lou Berger Sent: 16 November 2008 22:46 To: Nic Neate Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Perso= nal; ccamp@ops.ietf.org; ALU - Dimitri Papadimitriou Subject: RE: Agenda updated I agree with Dimitri. also, note: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Lou At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: >nick, > >you mention: > >"3.1 Association between LSPs in different sessions > > Segment recovery protecting LSPs may have a different endpoint > address from the corresponding protected LSP. The protected and > protecting LSPs are therefore in different Sessions. The Association > object of type 1 (recovery) is not effective in this case, as the > Association ID can only associate to an LSP ID within the same > Session." > >but segment recovery makes use of: > >"9.1. New Association Type Assignment > > > IANA has made the following assignment to the "Association Types" > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > "RSVP PARAMETERS" registry located at > http://www.iana.org/assignments/rsvp-parameters. > > Value Type > ----- ---- > 2 Resource Sharing (R) [RFC4873]" > >and states: > >"Consider the following topology: > > A---B---C---D---E---F > \ / > G---I > > In this topology, end-to-end protection and recovery is not possible > for an LSP going between node A and node F, but it is possible to > protect/recover a portion of the LSP. Specifically, if the LSP uses > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > can be established along the path [C,G,I,E]." > >[...] > >"Segment protection or restoration is signaled using a working LSP and > one or more segment recovery LSPs. Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path, > e.g., node E shown above. There is no specific requirement on LSP ID > value, Tunnel ID, and Extended Tunnel ID." > >so where is the issue ? > >-d. > > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, November 14, 2008 4:46 PM > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > Dimitri; Aria - Adrian Farrel Personal > > Cc: ccamp@ops.ietf.org > > Subject: FW: Agenda updated > > > > RFC 4873 authors, > > > > Just wanted to flag that I'm presenting a problem in segment > > recovery signaling on Monday, together with a suggested solution. > > > > Problem statement: > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > Suggested fix: > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > Nic > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian Farrel > > Personal > > Sent: 07 November 2008 19:29 > > To: ccamp@ops.ietf.org > > Subject: Agenda updated > > > > I have made some updates. > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > Please shout if there further issues. > > > > Thanks, > > Adrian > > > > From owner-ccamp@ops.ietf.org Tue Nov 18 06:20:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802893A67E4 for ; Tue, 18 Nov 2008 06:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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 2l0QoBYQIjSl for ; Tue, 18 Nov 2008 06:20:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 245623A6784 for ; Tue, 18 Nov 2008 06:20:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2RNS-000JAJ-Qd for ccamp-data@psg.com; Tue, 18 Nov 2008 14:16:26 +0000 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2RNN-000J9h-6Y for ccamp@ops.ietf.org; Tue, 18 Nov 2008 14:16:23 +0000 Received: from FRVELSBHS04.ad2.ad.alcatel.com ([155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mAIEFjP0025154; Tue, 18 Nov 2008 15:16:06 +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); Tue, 18 Nov 2008 15:16:05 +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: Agenda updated Date: Tue, 18 Nov 2008 15:16:02 +0100 Message-ID: <00275A5B436CA441900CB10936742A380161D40C@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda updated Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAA3sOeAABq6O2A= References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.datcon.co.uk> From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , "labn - Lou Berger" Cc: , "Aria - Adrian Farrel Personal" , X-OriginalArrivalTime: 18 Nov 2008 14:16:05.0846 (UTC) FILETIME=[31E85760:01C94988] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: hi nic, my 2 cents here below:=20 > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Tuesday, November 18, 2008 3:07 PM > To: labn - Lou Berger > Cc: IBryskin@advaoptical.com; Aria - Adrian Farrel Personal;=20 > ccamp@ops.ietf.org; PAPADIMITRIOU Dimitri > Subject: RE: Agenda updated >=20 > Hi Lou, >=20 > Following up on our conversation in CCAMP. >=20 > I think you agreed that the "Resource Sharing" association=20 > type 2 is not relevant to this discussion. >=20 > You also said that the intent of the statement from 3.2.1=20 > "processing and identification occur with respect to segment=20 > recovery LSPs" is to indicate that the procedures defined in=20 > RFC 4872 for setting the association ID to an LSP ID are not=20 > used. Instead, a unique identifier should be chosen by the=20 > association source (as suggested in our draft). >=20 > I find this quite a stretch, and think a clarification would=20 > improve the chances of interoperability. where is the stretch ? in end-to-end the source of the tunnel is the source of the association whereas in the segment case they are not the same. > I'm also concerned with the reuse of association type 1 with=20 > different semantics in segment recovery to those defined for=20 > end-to-end recovery. Consider the case where a segment=20 > recovery LSP is itself end-to-end protected. =20 what does this actually mean ? does it refer to the case where there are two 2 protecting segments ? > Then there will=20 > be two type 1 association objects, and the merge node must=20 > process each differently. How does the implementation you=20 > mentioned decide which is which? > > You also dismissed the other issues raised in=20 > draft-rhodes-rsvp-recovery-signaling relating to protection=20 > of recovery LSPs and overlaping protection. Please could you=20 > respond on the specific technical points raised in the draft? it is the same as the base case, if a segment recovery LSP is himself protected partially the source of the association will not be the source of protected recovery segment. =20 thanks, -d. > I'd be glad to meet up and discuss this in person while we're=20 > in Minneapolis. >=20 > Thanks, >=20 > Nic >=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of labn - Lou Berger > Sent: 16 November 2008 22:46 > To: Nic Neate > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal; ccamp@ops.ietf.org; ALU - Dimitri=20 > Papadimitriou > Subject: RE: Agenda updated >=20 > I agree with Dimitri. >=20 > also, note: >=20 > 3.2.1. Recovery Type Processing >=20 > Recovery type processing procedures are the same as those=20 > defined in > [RFC4872], but processing and identification occur with respect to > segment recovery LSPs. >=20 > Lou >=20 > At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: > >nick, > > > >you mention: > > > >"3.1 Association between LSPs in different sessions > > > > Segment recovery protecting LSPs may have a different endpoint > > address from the corresponding protected LSP. The protected and > > protecting LSPs are therefore in different Sessions. =20 > The Association > > object of type 1 (recovery) is not effective in this case, as the > > Association ID can only associate to an LSP ID within the same > > Session." > > > >but segment recovery makes use of: > > > >"9.1. New Association Type Assignment > > > > > > IANA has made the following assignment to the "Association Types" > > Registry (see [RFC4872]) in the "ASSOCIATION (object)"=20 > section of the > > "RSVP PARAMETERS" registry located at > > http://www.iana.org/assignments/rsvp-parameters. > > > > Value Type > > ----- ---- > > 2 Resource Sharing (R) [RFC4873]" > > > >and states: > > > >"Consider the following topology: > > > > A---B---C---D---E---F > > \ / > > G---I > > > > In this topology, end-to-end protection and recovery is=20 > not possible > > for an LSP going between node A and node F, but it is possible to > > protect/recover a portion of the LSP. Specifically, if=20 > the LSP uses > > a working path of [A,B,C,D,E,F], then a protection or=20 > restoration LSP > > can be established along the path [C,G,I,E]." > > > >[...] > > > >"Segment protection or restoration is signaled using a=20 > working LSP and > > one or more segment recovery LSPs. Each segment recovery LSP is > > signaled as an independent LSP. Specifically, the=20 > Sender_Template > > object uses the IP address of the node originating the=20 > recovery path, > > e.g., node C in the topology shown above, and the Session object > > contains the IP address of the node terminating the=20 > recovery path, > > e.g., node E shown above. There is no specific=20 > requirement on LSP ID > > value, Tunnel ID, and Extended Tunnel ID." > > > >so where is the issue ? > > > >-d. > > > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Friday, November 14, 2008 4:46 PM > > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > > Dimitri; Aria - Adrian Farrel Personal > > > Cc: ccamp@ops.ietf.org > > > Subject: FW: Agenda updated > > > > > > RFC 4873 authors, > > > > > > Just wanted to flag that I'm presenting a problem in segment > > > recovery signaling on Monday, together with a suggested solution. > > > > > > Problem statement: > > >=20 > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > > Suggested fix: > > >=20 > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > > > > Nic > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria -=20 > Adrian Farrel > > > Personal > > > Sent: 07 November 2008 19:29 > > > To: ccamp@ops.ietf.org > > > Subject: Agenda updated > > > > > > I have made some updates. > > > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > > > Please shout if there further issues. > > > > > > Thanks, > > > Adrian > > > > > > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Nov 18 07:06:20 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 64D943A688F for ; Tue, 18 Nov 2008 07:06:20 -0800 (PST) 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 5IWin824X8v5 for ; Tue, 18 Nov 2008 07:06:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54C023A6925 for ; Tue, 18 Nov 2008 07:05:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2S4w-000Lly-H0 for ccamp-data@psg.com; Tue, 18 Nov 2008 15:01:22 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2S4q-000LlQ-Hb for ccamp@ops.ietf.org; Tue, 18 Nov 2008 15:01:19 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 317F13A688F; Tue, 18 Nov 2008 07:01:13 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)' to Experimental RFC Message-Id: <20081118150114.317F13A688F@core3.amsl.com> Date: Tue, 18 Nov 2008 07:01:14 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: The IESG has approved the following document: - 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) ' as an Experimental RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt Technical Summary This experimental document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. Working Group Summary No controversy reported. These protocol extensions have full support of the working group, but are being submitted as experimental because there is no immediate intention to build or deploy product containing these features. See PROTO writeup by Adrian Farrel (posted to the tracker by Amy Vezza). Document Quality No existing implementations. No announced plans. The document has had ample review for a experimental straightforward extension to an existing protocol. An alternate approach that was considered, along with the reason that it was not selected, is discussed in an Appendix. Personnel Adrian Farrel is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. From owner-ccamp@ops.ietf.org Tue Nov 18 07:11:31 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568283A688F for ; Tue, 18 Nov 2008 07:11:31 -0800 (PST) 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=[AWL=-0.000, 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 wq8Slp5aKTpk for ; Tue, 18 Nov 2008 07:11:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62AC13A687E for ; Tue, 18 Nov 2008 07:11:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2SB6-000MCn-BC for ccamp-data@psg.com; Tue, 18 Nov 2008 15:07:44 +0000 Received: from [192.91.191.38] (helo=enfiets1.dataconnection.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2SAz-000MC6-MA for ccamp@ops.ietf.org; Tue, 18 Nov 2008 15:07:41 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 18 Nov 2008 15:07:57 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Tue, 18 Nov 2008 15:07:39 +0000 From: Nic Neate To: Aria - Adrian Farrel Personal CC: "ccamp@ops.ietf.org" , labn - Lou Berger , ALU - Dimitri Papadimitriou Date: Tue, 18 Nov 2008 15:07:36 +0000 Subject: RE: Clearing up your misunderstanding of the Association ID Thread-Topic: Clearing up your misunderstanding of the Association ID Thread-Index: AclJhfbNLbyZOjCkQsmXDXM+Gp8/+QACLLEg Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4655F3@ENFIMBOX1.ad.datcon.co.uk> References: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe> In-Reply-To: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to = changing the specific procedures defined in 4872 for setting the associatio= n ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873.= However, I still have some concerns about interworking of end-to-end and = segment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try= to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think y= ou may have misread the relevant RFCs. I don't believe any new Association = ID type is needed to achieve the function: we can simply use the 4872 assoc= iation type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that i= n 4873, the context is not end-to-end LSP recovery so the restriction on t= he Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of yo= ur issues go away. Cheers, Adrian From owner-ccamp@ops.ietf.org Tue Nov 18 07:58: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 C6E1628C156 for ; Tue, 18 Nov 2008 07:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 GgsJJym3aRlt for ; Tue, 18 Nov 2008 07:58:58 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FB4C28C152 for ; Tue, 18 Nov 2008 07:58:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2Sub-000Or7-9P for ccamp-data@psg.com; Tue, 18 Nov 2008 15:54:45 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2SuO-000Opw-HO for ccamp@ops.ietf.org; Tue, 18 Nov 2008 15:54:41 +0000 Received: from [172.17.196.165] ([12.167.162.5]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id mAIFsQbZ032208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 07:54:31 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4922E533.6010400@grotto-networking.com> Date: Tue, 18 Nov 2008 09:54:27 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Wson (E-mail)" , ccamp Subject: Materials for Semi-Formal WSON meeting today... Content-Type: multipart/alternative; boundary="------------070600070603090202080004" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------070600070603090202080004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON discussion session. When I last checked this room was set up in "meeting room" configuration, that is, everyone around a big table. This is good for discussion but there wasn't a projector. Some of the slides we were going to use are: Existing optical draft discussion: http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt Optical Impairment: http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt Please download these so you can follow along. Others with slides, please let folks know where to get them so folks can follow along on their laptops. Also, I highly recommend that folks go to the ITU-T web page for the G series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup the PDFs for *G.671* (characteristics of optical components and subsystems), *G.680* (transfer functions of optical networks elements), and *G.697* (optical monitoring). No excuses! these are free and you should have these if you are interested in optical impairments. Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------070600070603090202080004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON discussion session.
When I last checked this room was set up in "meeting room" configuration, that is, everyone around a big table. This is good for discussion but there wasn't a projector. Some of the slides we were going to use are:

Existing optical draft discussion:
http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt

Optical Impairment:
http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt
http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt

Please download these so you can follow along. Others with slides, please let folks know where to get them so folks can follow along on their laptops.

Also, I  highly recommend that folks go to the ITU-T web page for the G series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup the PDFs for G.671 (characteristics of optical components and subsystems), G.680 (transfer functions of optical networks elements), and G.697 (optical monitoring). No excuses! these are free and you should have these if you are interested in optical impairments.

Regards

Greg
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------070600070603090202080004-- From owner-ccamp@ops.ietf.org Tue Nov 18 08:11:14 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 7B4D63A6A30 for ; Tue, 18 Nov 2008 08:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 cz10ezMUTJHk for ; Tue, 18 Nov 2008 08:11:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8513C3A6808 for ; Tue, 18 Nov 2008 08:11:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2T5R-000PX7-EE for ccamp-data@psg.com; Tue, 18 Nov 2008 16:05:57 +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 1L2T5F-000PWL-Hb for ccamp@ops.ietf.org; Tue, 18 Nov 2008 16:05:54 +0000 Received: (qmail 537 invoked by uid 0); 18 Nov 2008 16:05:38 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy2.bluehost.com with SMTP; 18 Nov 2008 16:05:38 -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=eyudLN17gDzm7hAuW9EItqjXdS7+IyoZbUY1DRR7kw+N+oNWWoMlYM/+VLWO0OtxExURZlUNVEJ4a6sRjjJAiNwWq479v2v6TK2Rvwa1ftasPH2JBPVYR27eawmwx6Us; 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 1L2T4p-0002Bh-0I; Tue, 18 Nov 2008 09:05:19 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Nov 2008 11:05:16 -0600 To: Nic Neate From: Lou Berger Subject: RE: Agenda updated Cc: Lou Berger , "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" , ALU - Dimitri Papadimitriou In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.da tcon.co.uk> References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.datcon.co.uk> 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: Nic, See below. At 08:06 AM 11/18/2008, Nic Neate wrote: >Hi Lou, > >Following up on our conversation in CCAMP. > >I think you agreed that the "Resource Sharing" association type 2 is >not relevant to this discussion. > >You also said that the intent of the statement from 3.2.1 >"processing and identification occur with respect to segment >recovery LSPs" is to indicate that the procedures defined in RFC >4872 for setting the association ID to an LSP ID are not >used. Instead, a unique identifier should be chosen by the >association source (as suggested in our draft). > >I find this quite a stretch, and think a clarification would improve >the chances of interoperability. As you know, in there's always opportunity for more detailed discussion in any document and that there will always be someone who doesn't understand the more detailed explanation. It's up to the author's and the WG to agree that a draft is sufficient. At the time the document was written, we did. I accept that more language could be helpful to those new to segment recovery. As I suggested to you, I believe the proper way to address this (and to ask for and to get formal clarification) is to open an Errata. >I'm also concerned with the reuse of association type 1 with >different semantics in segment recovery to those defined for >end-to-end recovery. How are the semantics different? Per RFC4872: 16.1. Format The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) has the format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Association Type: 16 bits Indicates the type of association being identified. Note that this value is considered when determining association. The following are values defined in this document. Value Type ----- ---- 0 Reserved 1 Recovery (R) Association ID: 16 bits A value assigned by the LSP head-end. When combined with the Association Type and Association Source, this value uniquely identifies an association. Association Source: 4 or 16 bytes An IPv4 or IPv6 address, respectively, that is associated to the node that originated the association. And RFC4873 says: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP. >Consider the case where a segment recovery LSP is itself end-to-end >protected. Then there will be two type 1 association objects, and >the merge node must process each differently. yes, as is explicity stated in the RFC. >How does the implementation you mentioned decide which is which? What protocol question are you asking here? If you want to see code, most folks don't make that available or charge a fee (I know of some sources of such code, and can provide this info offline if you'd like). >You also dismissed the other issues raised in >draft-rhodes-rsvp-recovery-signaling relating to protection of >recovery LSPs and overlaping protection. Per RFC4873: Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path, e.g., node E shown above. There is no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID. Values for these fields are selected normally, including consideration for the make-before- break concept (as described in [RFC3209]). Intermediate nodes follow standard signaling procedures when processing segment recovery LSPs. A segment recovery LSP may be protected itself using segment or end- to-end protection/restoration. Note, in PSC environments, it may be desirable to construct the Sender_Template and Session objects per [RFC4090]. When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872]. The ASSOCIATION object is used to associate recovery LSPs with the LSP they are protecting. >Please could you respond on the specific technical points raised in the draft? I suggest bringing points you'd like to discuss to the list. Although, I think resolution of the basic understanding of segment recovery is needed to move the discussion further. Again, I suggest filing the errata... Lou >I'd be glad to meet up and discuss this in person while we're in Minneapolis. > >Thanks, > >Nic > > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of labn - Lou Berger >Sent: 16 November 2008 22:46 >To: Nic Neate >Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian >Farrel Personal; ccamp@ops.ietf.org; ALU - Dimitri Papadimitriou >Subject: RE: Agenda updated > >I agree with Dimitri. > >also, note: > > 3.2.1. Recovery Type Processing > > Recovery type processing procedures are the same as those defined in > [RFC4872], but processing and identification occur with respect to > segment recovery LSPs. > >Lou > >At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: > >nick, > > > >you mention: > > > >"3.1 Association between LSPs in different sessions > > > > Segment recovery protecting LSPs may have a different endpoint > > address from the corresponding protected LSP. The protected and > > protecting LSPs are therefore in different Sessions. The Association > > object of type 1 (recovery) is not effective in this case, as the > > Association ID can only associate to an LSP ID within the same > > Session." > > > >but segment recovery makes use of: > > > >"9.1. New Association Type Assignment > > > > > > IANA has made the following assignment to the "Association Types" > > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > > "RSVP PARAMETERS" registry located at > > http://www.iana.org/assignments/rsvp-parameters. > > > > Value Type > > ----- ---- > > 2 Resource Sharing (R) [RFC4873]" > > > >and states: > > > >"Consider the following topology: > > > > A---B---C---D---E---F > > \ / > > G---I > > > > In this topology, end-to-end protection and recovery is not possible > > for an LSP going between node A and node F, but it is possible to > > protect/recover a portion of the LSP. Specifically, if the LSP uses > > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > > can be established along the path [C,G,I,E]." > > > >[...] > > > >"Segment protection or restoration is signaled using a working LSP and > > one or more segment recovery LSPs. Each segment recovery LSP is > > signaled as an independent LSP. Specifically, the Sender_Template > > object uses the IP address of the node originating the recovery path, > > e.g., node C in the topology shown above, and the Session object > > contains the IP address of the node terminating the recovery path, > > e.g., node E shown above. There is no specific requirement on LSP ID > > value, Tunnel ID, and Extended Tunnel ID." > > > >so where is the issue ? > > > >-d. > > > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Friday, November 14, 2008 4:46 PM > > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > > Dimitri; Aria - Adrian Farrel Personal > > > Cc: ccamp@ops.ietf.org > > > Subject: FW: Agenda updated > > > > > > RFC 4873 authors, > > > > > > Just wanted to flag that I'm presenting a problem in segment > > > recovery signaling on Monday, together with a suggested solution. > > > > > > Problem statement: > > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > > Suggested fix: > > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > > > > Nic > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian Farrel > > > Personal > > > Sent: 07 November 2008 19:29 > > > To: ccamp@ops.ietf.org > > > Subject: Agenda updated > > > > > > I have made some updates. > > > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > > > Please shout if there further issues. > > > > > > Thanks, > > > Adrian > > > > > > From owner-ccamp@ops.ietf.org Tue Nov 18 08:12: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 A12A73A6A30 for ; Tue, 18 Nov 2008 08:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.040, 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 DKHr48F67RZX for ; Tue, 18 Nov 2008 08:12:54 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C55F28C13E for ; Tue, 18 Nov 2008 08:12:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2T86-000Pgc-I5 for ccamp-data@psg.com; Tue, 18 Nov 2008 16:08:42 +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 1L2T80-000PgC-5G for ccamp@ops.ietf.org; Tue, 18 Nov 2008 16:08:39 +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 mAIG8Tuh005414; Tue, 18 Nov 2008 16:08:29 GMT Received: from your029b8cecfe ([130.129.31.98]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAIG8Rj4005373; Tue, 18 Nov 2008 16:08:28 GMT Message-ID: <141ADD61D0FD4515B7D0C382666267D7@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Greg Bernstein" , "Wson \(E-mail\)" , "ccamp" References: <4922E533.6010400@grotto-networking.com> Subject: Re: Materials for Semi-Formal WSON meeting today... Date: Tue, 18 Nov 2008 16:08:16 -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 Greg, Thanks for taking care of this. Just for the record... The meeting isn't really "semi-formal." That is, it is not an IETF meeting, but a meeting of co-authors and interested parties. Cheers, Adrian ----- Original Message ----- From: "Greg Bernstein" To: "Wson (E-mail)" ; "ccamp" Sent: Tuesday, November 18, 2008 3:54 PM Subject: Materials for Semi-Formal WSON meeting today... > Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in > the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON > discussion session. > When I last checked this room was set up in "meeting room" > configuration, that is, everyone around a big table. This is good for > discussion but there wasn't a projector. Some of the slides we were > going to use are: > > Existing optical draft discussion: > http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt > > Optical Impairment: > http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt > http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt > > Please download these so you can follow along. Others with slides, > please let folks know where to get them so folks can follow along on > their laptops. > > Also, I highly recommend that folks go to the ITU-T web page for the G > series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup > the PDFs for *G.671* (characteristics of optical components and > subsystems), *G.680* (transfer functions of optical networks elements), > and *G.697* (optical monitoring). No excuses! these are free and you > should have these if you are interested in optical impairments. > > Regards > > Greg > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > From owner-ccamp@ops.ietf.org Tue Nov 18 08:26: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 2DDAA28C1A7 for ; Tue, 18 Nov 2008 08:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, 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 9Cz3eHXzMzvS for ; Tue, 18 Nov 2008 08:26:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D77AA28C17E for ; Tue, 18 Nov 2008 08:26:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2TLb-0000Z4-9Y for ccamp-data@psg.com; Tue, 18 Nov 2008 16:22:39 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2TLP-0000Xv-6g for ccamp@ops.ietf.org; Tue, 18 Nov 2008 16:22:32 +0000 Received: from [172.17.196.165] ([12.167.162.5]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id mAIGMN5J065045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 08:22:25 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4922EBC1.3060801@grotto-networking.com> Date: Tue, 18 Nov 2008 10:22:25 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 CC: ccamp Subject: Re: Materials for Semi-Formal WSON meeting today... References: <4922E533.6010400@grotto-networking.com> <141ADD61D0FD4515B7D0C382666267D7@your029b8cecfe> In-Reply-To: <141ADD61D0FD4515B7D0C382666267D7@your029b8cecfe> Content-Type: multipart/alternative; boundary="------------050608080100010602030803" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------050608080100010602030803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Whoops, sorry about that, I meant "semi-*informal*". This is not an IETF meeting, but an somewhat organized meeting of co-authors and interested parties. Thanks Greg Adrian Farrel wrote: > Hi Greg, > > Thanks for taking care of this. > > Just for the record... > > The meeting isn't really "semi-formal." That is, it is not an IETF > meeting, but a meeting of co-authors and interested parties. > > Cheers, > Adrian > ----- Original Message ----- From: "Greg Bernstein" > > To: "Wson (E-mail)" ; "ccamp" > > Sent: Tuesday, November 18, 2008 3:54 PM > Subject: Materials for Semi-Formal WSON meeting today... > > >> Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in >> the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON >> discussion session. >> When I last checked this room was set up in "meeting room" >> configuration, that is, everyone around a big table. This is good for >> discussion but there wasn't a projector. Some of the slides we were >> going to use are: >> >> Existing optical draft discussion: >> http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt >> >> >> Optical Impairment: >> http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt >> >> http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt >> >> >> Please download these so you can follow along. Others with slides, >> please let folks know where to get them so folks can follow along on >> their laptops. >> >> Also, I highly recommend that folks go to the ITU-T web page for the G >> series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup >> the PDFs for *G.671* (characteristics of optical components and >> subsystems), *G.680* (transfer functions of optical networks elements), >> and *G.697* (optical monitoring). No excuses! these are free and you >> should have these if you are interested in optical impairments. >> >> Regards >> >> Greg >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050608080100010602030803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Whoops, sorry about that, I meant "semi-informal". This is not an IETF meeting, but an somewhat organized meeting of co-authors and interested parties.

Thanks

Greg

Adrian Farrel wrote:
Hi Greg,

Thanks for taking care of this.

Just for the record...

The meeting isn't really "semi-formal." That is, it is not an IETF meeting, but a meeting of co-authors and interested parties.

Cheers,
Adrian
----- Original Message ----- From: "Greg Bernstein" <gregb@grotto-networking.com>
To: "Wson (E-mail)" <wson@grotto-networking.com>; "ccamp" <ccamp@ops.ietf.org>
Sent: Tuesday, November 18, 2008 3:54 PM
Subject: Materials for Semi-Formal WSON meeting today...


Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in
the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON
discussion session.
When I last checked this room was set up in "meeting room"
configuration, that is, everyone around a big table. This is good for
discussion but there wasn't a projector. Some of the slides we were
going to use are:

Existing optical draft discussion:
http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt

Optical Impairment:
http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt
http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt

Please download these so you can follow along. Others with slides,
please let folks know where to get them so folks can follow along on
their laptops.

Also, I  highly recommend that folks go to the ITU-T web page for the G
series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup
the PDFs for *G.671* (characteristics of optical components and
subsystems), *G.680* (transfer functions of optical networks elements),
and *G.697* (optical monitoring). No excuses! these are free and you
should have these if you are interested in optical impairments.

Regards

Greg

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237 






-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050608080100010602030803-- From owner-ccamp@ops.ietf.org Tue Nov 18 09:20:19 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170E73A6AFF for ; Tue, 18 Nov 2008 09:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.364 X-Spam-Level: X-Spam-Status: No, score=-101.364 tagged_above=-999 required=5 tests=[AWL=1.236, 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 4ucD+5vnoRct for ; Tue, 18 Nov 2008 09:20:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1ECAF3A6AFE for ; Tue, 18 Nov 2008 09:20:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2UAT-00048u-7h for ccamp-data@psg.com; Tue, 18 Nov 2008 17:15: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 1L2UAI-00047S-05 for ccamp@ops.ietf.org; Tue, 18 Nov 2008 17:15:07 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 63DCF28C1F1; Tue, 18 Nov 2008 09:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081118171501.63DCF28C1F1@core3.amsl.com> Date: Tue, 18 Nov 2008 09:15:01 -0800 (PST) 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 : Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-gmpls-vcat-lcas-06.txt Pages : 22 Date : 2008-11-18 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-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-vcat-lcas-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-18090328.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Tue Nov 18 10:42:30 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 F282F3A69CA for ; Tue, 18 Nov 2008 10:42:30 -0800 (PST) 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 FcmWzT+fwkWT for ; Tue, 18 Nov 2008 10:42:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 297643A6885 for ; Tue, 18 Nov 2008 10:42:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2VRV-00094A-Rs for ccamp-data@psg.com; Tue, 18 Nov 2008 18:36:53 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2VRQ-00093q-K8 for ccamp@ops.ietf.org; Tue, 18 Nov 2008 18:36:51 +0000 Received: from [130.129.28.125] ([130.129.28.125]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id mAIIak7k037846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 10:36:47 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <49230B3F.9010405@grotto-networking.com> Date: Tue, 18 Nov 2008 12:36:47 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp Subject: VCAT/LCAS draft update... 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 folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object from the MLN extensions draft. We define a new VCAT TLV for use in the aforementioned object. All procedures and encodings otherwise are the same as the previous draft. Note that the draft will now be contingent on the MLN extensions draft moving forward. A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.txt Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From owner-ccamp@ops.ietf.org Tue Nov 18 14:38:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7392928C294 for ; Tue, 18 Nov 2008 14:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 tkyPmAmSoHtp for ; Tue, 18 Nov 2008 14:38:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FCCE28C291 for ; Tue, 18 Nov 2008 14:38:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2Z9a-000NiL-8b for ccamp-data@psg.com; Tue, 18 Nov 2008 22:34:38 +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 1L2Z9T-000NhG-OU for ccamp@ops.ietf.org; Tue, 18 Nov 2008 22:34:34 +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 mAIMYRxS013765; Tue, 18 Nov 2008 22:34:28 GMT Received: from your029b8cecfe ([130.129.31.98]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mAIMYQN2013744; Tue, 18 Nov 2008 22:34:27 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Nic Neate" Cc: References: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe> <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4655F3@ENFIMBOX1.ad.datcon.co.uk> Subject: Re: Clearing up your misunderstanding of the Association ID Date: Tue, 18 Nov 2008 22:34:14 -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: So... Nic and I sat down today and discussed this particluar issue: how to interpret the Association ID in a received Path message in order to associate a new LSP with some other LSP at a merge point. There are two cases that arise. If the new LSP is part of a segment protection relationship, the Association ID is a unique "set identifier" in the context of the Association Source. If the LSP is part of an end-to-end protection relationship, the Association ID identifies the LSP ID of the protection partner. Nic's concern (and he convinced me for a while :-) is that there is an issue with distinguishing this case when a segment protection LSP is, itself, protected along its whole path in an end-to-end manner. Having thought about this more, I believe the following processing rules that can be applied to make this work. I would be interested in any use cases (in particular message arrival variants) that anyone believes breaks these rules. For each Association Object on the received Path message... 1. Look for an existing LSP with association object that matches {Association Source, Association ID} from the new Path message. If found, this is segment protection protecting from the Association Source to this node. Stop. 2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID} and with LSP ID equal to received Association ID. The Association Source can (and probably should) also be checked against the sender source address on the matched LSP. If found, this is end-to-end protection from Association Source to dest. Note that there may be multiple Association objects on a Path message. Note also, that 4872 requires the use of the same Session specifically to enable the use of the Association ID to LSP ID mapping. As far as I can see, this addresses all cases. Cheers, Adrian ----- Original Message ----- From: "Nic Neate" To: "Aria - Adrian Farrel Personal" Cc: ; "labn - Lou Berger" ; "ALU - Dimitri Papadimitriou" Sent: Tuesday, November 18, 2008 3:07 PM Subject: RE: Clearing up your misunderstanding of the Association ID Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to changing the specific procedures defined in 4872 for setting the association ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873. However, I still have some concerns about interworking of end-to-end and segment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think you may have misread the relevant RFCs. I don't believe any new Association ID type is needed to achieve the function: we can simply use the 4872 association type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that in 4873, the context is not end-to-end LSP recovery so the restriction on the Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of your issues go away. Cheers, Adrian From owner-ccamp@ops.ietf.org Wed Nov 19 14:06:31 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1709F3A6931 for ; Wed, 19 Nov 2008 14:06:31 -0800 (PST) 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.051, 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 Yc4ahkxkN9hb for ; Wed, 19 Nov 2008 14:06:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF5783A6895 for ; Wed, 19 Nov 2008 14:06:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2v6Y-000Bys-QC for ccamp-data@psg.com; Wed, 19 Nov 2008 22:00:58 +0000 Received: from [192.91.191.39] (helo=enfiets2.dataconnection.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L2v6S-000ByN-V4 for ccamp@ops.ietf.org; Wed, 19 Nov 2008 22:00:55 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 19 Nov 2008 22:01:38 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Wed, 19 Nov 2008 22:00:55 +0000 From: Nic Neate To: Aria - Adrian Farrel Personal CC: "ccamp@ops.ietf.org" Date: Wed, 19 Nov 2008 22:00:49 +0000 Subject: RE: Clearing up your misunderstanding of the Association ID Thread-Topic: Clearing up your misunderstanding of the Association ID Thread-Index: AclJzdNZSY7CnagwTjiuqh0mbygxywAqn7pQ Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4B2B5E@ENFIMBOX1.ad.datcon.co.uk> References: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe> <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4655F3@ENFIMBOX1.ad.datcon.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian, As we discussed earlier, there's also an Association ID / LSP ID space over= lap issue here that's worth drawing out. The branch node is generating ASSOCIATION objects for both end-to-end prote= ction and segment protection, and always uses the same Association Type and= Source. The Association IDs that it chooses must therefore not clash. In= the end-to-end case, the Association ID is actually an LSP ID. Your first= rule for the merge node is to check the Association ID against other segme= nt Association IDs. Therefore, LSP IDs allocated to end-to-end protected L= SPs must not clash with (existing or future) segment Association IDs. LSP IDs are actually allocated by the management tool / MIB interface (mpls= TunnelInstance). I think this therefore amounts to a restriction on the MI= B interface / management tool. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 22:34 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Re: Clearing up your misunderstanding of the Association ID So... Nic and I sat down today and discussed this particluar issue: how to interp= ret the Association ID in a received Path message in order to associate a n= ew LSP with some other LSP at a merge point. There are two cases that arise. If the new LSP is part of a segment protect= ion relationship, the Association ID is a unique "set identifier" in the co= ntext of the Association Source. If the LSP is part of an end-to-end protec= tion relationship, the Association ID identifies the LSP ID of the protecti= on partner. Nic's concern (and he convinced me for a while :-) is that there is an issu= e with distinguishing this case when a segment protection LSP is, itself, p= rotected along its whole path in an end-to-end manner. Having thought about this more, I believe the following processing rules th= at can be applied to make this work. I would be interested in any use cases= (in particular message arrival variants) that anyone believes breaks these= rules. For each Association Object on the received Path message... 1. Look for an existing LSP with association object that matches {Associati= on Source, Association ID} from the new Path message. If found, this is seg= ment protection protecting from the Association Source to this node. Stop. 2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID= } and with LSP ID equal to received Association ID. The Association Source = can (and probably should) also be checked against the sender source address= on the matched LSP. If found, this is end-to-end protection from Associati= on Source to dest. Note that there may be multiple Association objects on a Path message. Note= also, that 4872 requires the use of the same Session specifically to enabl= e the use of the Association ID to LSP ID mapping. As far as I can see, this addresses all cases. Cheers, Adrian ----- Original Message ----- From: "Nic Neate" To: "Aria - Adrian Farrel Personal" Cc: ; "labn - Lou Berger" ; "ALU - Di= mitri Papadimitriou" Sent: Tuesday, November 18, 2008 3:07 PM Subject: RE: Clearing up your misunderstanding of the Association ID Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to = changing the specific procedures defined in 4872 for setting the associatio= n ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873. However, I still have some concerns about interworking of end-to-end and se= gment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try= to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think y= ou may have misread the relevant RFCs. I don't believe any new Association = ID type is needed to achieve the function: we can simply use the 4872 assoc= iation type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that i= n 4873, the context is not end-to-end LSP recovery so the restriction on t= he Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of yo= ur issues go away. Cheers, Adrian From owner-ccamp@ops.ietf.org Thu Nov 20 16:43: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 631A43A6873 for ; Thu, 20 Nov 2008 16:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=-3.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 jqZgtE2TEIWS for ; Thu, 20 Nov 2008 16:43:27 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92AD828C155 for ; Thu, 20 Nov 2008 16:43:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L3K1H-000IAg-9s for ccamp-data@psg.com; Fri, 21 Nov 2008 00:37:11 +0000 Received: from [216.82.241.147] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L3K18-000IAC-KI for ccamp@ops.ietf.org; Fri, 21 Nov 2008 00:37:04 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1227227820!4436611!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 8255 invoked from network); 21 Nov 2008 00:37:01 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 21 Nov 2008 00:37:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mAL0b0hG012556 for ; Thu, 20 Nov 2008 19:37:00 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mAL0athX012530 for ; Thu, 20 Nov 2008 19:36:55 -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: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt Date: Thu, 20 Nov 2008 19:36:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt Thread-Index: AclLcSBkC9PN1RWSRrquCv8jL/wuaA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-02.txt Please send your comments to the mailing list prior to EOB Dec 5. Thanks, Deborah and Adrian From owner-ccamp@ops.ietf.org Fri Nov 21 07:56: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 4EADD3A6982 for ; Fri, 21 Nov 2008 07:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.760, 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 PkUpRG8Ox2LP for ; Fri, 21 Nov 2008 07:56:32 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CD033A697A for ; Fri, 21 Nov 2008 07:56:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L3YFx-000EGK-B8 for ccamp-data@psg.com; Fri, 21 Nov 2008 15:49:17 +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 1L3YFr-000EFi-5e for ccamp@ops.ietf.org; Fri, 21 Nov 2008 15:49:14 +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 mALFn643029775; Fri, 21 Nov 2008 15:49:06 GMT Received: from your029b8cecfe ([130.129.79.220]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mALFn5an029762; Fri, 21 Nov 2008 15:49:06 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Loa Andersson" Subject: working group last call on MPLS and GMPLS security framework Date: Fri, 21 Nov 2008 15:48:57 -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: The MPLS working group is holding a last call on this draft. It is very important that you review it and comment. Please send comments to the MPLS list if you are subscribed. Otherwise then them to CCAMP and I will forward them. Thanks, Adrian ----- Original Message ----- From: "Loa Andersson" To: Cc: "Ross Callon" ; "David Ward" Sent: Friday, November 21, 2008 2:58 PM Subject: [mpls] working group last call on MPLS and GMPLS security framework > Working Group, > > this is to start a two week working group last call on: > > Security Framework for MPLS and GMPLS Networks > draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt > > please send your comments to the working group mailing list or > directly to the wg co-chairs. > > This working group last will end EOB Fri Dec 5 2008. > > Loa and Geoge > > -- > > > Loa Andersson > > Sr Strategy and Standards Manager > Redback Networks phone: +46 8 632 77 14 > An Ericsson company > email: > loa.andersson@redback.com > loa@pi.nu > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From 2008colo2011@gmail.com Fri Nov 21 18:00:00 2008 Return-Path: <2008colo2011@gmail.com> 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 567D43A68E8 for ; Fri, 21 Nov 2008 18:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofuAEBO58WaS for ; Fri, 21 Nov 2008 17:59:59 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 7A4C53A6834 for ; Fri, 21 Nov 2008 17:59:59 -0800 (PST) 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 <0KAP009MHPJIKX00@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Fri, 21 Nov 2008 22:59:43 -0300 (ART) Date: Fri, 21 Nov 2008 23:02:20 -0300 From: "2008colo2011@gmail.com" <2008colo2011@gmail.com> Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samsung LCD 19" To: CORE2DUO <2008colo2011@gmail.com> Message-id: <383-22008116222220849@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 TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B CEL: 15-3197-5821 EMail: 2008colo2011@gmail=2Ecom -Modelo: CORE 2 DUO -Procesador: E7200 CORE DUO 2=2E53 3MB cache 775 BOX 3 a=F1os de garantia -Motherboard: Asus P5GC-MX Socket 775 BOX=20 -Memoria: DDR2 2GB 667MHZ -Placa de video: PCI-E 512MB NX8400GS-TD256E MSI -Disco r=EDgido: 250GB SATA 2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 integrada -Placa de sonido: 6 canales -Puertos: 2USB frontales y 4USB traseros -Gabinete: SENTEY ATX c2 coolers fuente 500W -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 1/2 -Garantia equipo 12 meses -Sistema operativo instalado y funcionando FULL, todos los programas y uti= lidades -Monitor: LCD 19" Samsung 943NWX 3 a=F1os de garantia -PRECIO $2649 FINAL (IVA inc) Consulte otras configuraciones a medida, notebooks, camaras digitales y mu= cho mas From owner-ccamp@ops.ietf.org Mon Nov 24 06:24:04 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 20C5D3A690B for ; Mon, 24 Nov 2008 06:24:04 -0800 (PST) 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 Oli99Ybqw3ji for ; Mon, 24 Nov 2008 06:24:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B1C93A683A for ; Mon, 24 Nov 2008 06:24:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L4cFi-000EMD-9H for ccamp-data@psg.com; Mon, 24 Nov 2008 14:17:26 +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 1L4cFd-000ELX-JM for ccamp@ops.ietf.org; Mon, 24 Nov 2008 14:17:23 +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 mAOEHHr6025679 for ; Mon, 24 Nov 2008 14:17:18 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 mAOEHGL6025663 for ; Mon, 24 Nov 2008 14:17:17 GMT Message-ID: <03A5339A999247849861E8DB3D331DB3@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: [OSPF] WG Last Call on draft-ietf-ospf-te-node-addr-05.txt Date: Mon, 24 Nov 2008 14:17:12 -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 CCAMP, This last call in the OSPF working group may be of interest to you. Adrian ----- Original Message ----- From: "Acee Lindem" To: "OSPF List" Sent: Sunday, November 23, 2008 8:09 PM Subject: [OSPF] WG Last Call on draft-ietf-ospf-te-node-addr-05.txt > This starts the WG last for "Advertising a Router's Local Addresses > in OSPF TE Extensions" - draft-ietf-ospf-te-node-addr-05.txt. It will > conclude on Monday, December 8th, 2008 at 12:00 AM. > > This document was previously WG last called about 2 years back. We > delayed advancing it in our to align with the ASON requirements. With > the addition of the IPv4 and IPv6 prefix length, we now feel it will > be usable for ASCON as well. > > Thanks, > Acee & Abhay > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From 2008note2111@gmail.com Mon Nov 24 07:35:29 2008 Return-Path: <2008note2111@gmail.com> 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 318433A6A7D for ; Mon, 24 Nov 2008 07:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 2VH9ek+AK7gr for ; Mon, 24 Nov 2008 07:35:28 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 3C4563A6A65 for ; Mon, 24 Nov 2008 07:35:28 -0800 (PST) Received: from localhost ([190.48.106.247]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KAU00C99GKV2BK0@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Mon, 24 Nov 2008 12:34:08 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Mon, 24 Nov 2008 13:34:15 +0100 Date: Mon, 24 Nov 2008 13:34:15 +0100 From: "2008note2111@gmail.com" <2008note2111@gmail.com> Subject: COMPUTADORA ATHLON COMPLETA UNICA! ATHLON 5000+ GeForce 6100 USD265 To: ATHLON <2008note2111@gmail.com> Message-id: <3819-2200811124123415609@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII 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 TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B EMail: 2008note2111@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: 160 GB SATA2 -Medio optico: ReGrabadora de DVD Hewlett Packard 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 9024 -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=2E Microsoft Windows XP SP3 -PRECIO USD265 FINAL (Facturado) From mrv@airtelbroadband.in Mon Nov 24 15:59: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 BF05D3A67FC for ; Mon, 24 Nov 2008 15:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.713 X-Spam-Level: X-Spam-Status: No, score=-43.713 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9ObgBrrkoMo for ; Mon, 24 Nov 2008 15:59:54 -0800 (PST) Received: from server.dynapumpinc.com (dynapilot.dynapumpinc.com [209.3.86.162]) by core3.amsl.com (Postfix) with SMTP id 552F53A6A96 for ; Mon, 24 Nov 2008 15:59:53 -0800 (PST) To: Subject: all the rules are broken From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081124235953.552F53A6A96@core3.amsl.com> Date: Mon, 24 Nov 2008 15:59:53 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From mathilde.riallotp@agglo-plainecentrale94.fr Wed Nov 26 03:43:47 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112C03A694A for ; Wed, 26 Nov 2008 03:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2pq4iQJbMYG for ; Wed, 26 Nov 2008 03:43:46 -0800 (PST) Received: from ppp-58-9-189-12.revip2.asianet.co.th (ppp-58-9-189-12.revip2.asianet.co.th [58.9.189.12]) by core3.amsl.com (Postfix) with SMTP id B5D853A680D for ; Wed, 26 Nov 2008 03:43:43 -0800 (PST) To: Subject: Sport stakes rise From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126114344.B5D853A680D@core3.amsl.com> Date: Wed, 26 Nov 2008 03:43:43 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-ccamp@ops.ietf.org Thu Nov 27 03:47: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 86DE93A6CD2 for ; Thu, 27 Nov 2008 03:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=-0.841, 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 l43QhtgW3pDg for ; Thu, 27 Nov 2008 03:47:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30ACC3A6CD1 for ; Thu, 27 Nov 2008 03:47:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5fFR-000FJL-2o for ccamp-data@psg.com; Thu, 27 Nov 2008 11:41:29 +0000 Received: from [192.91.191.38] (helo=enfiets1.dataconnection.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5fFA-000FIO-M5 for ccamp@ops.ietf.org; Thu, 27 Nov 2008 11:41:17 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 27 Nov 2008 11:41:35 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Thu, 27 Nov 2008 11:41:24 +0000 From: Nic Neate To: Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" Date: Thu, 27 Nov 2008 11:41:22 +0000 Subject: FW: Clearing up your misunderstanding of the Association ID Thread-Topic: Clearing up your misunderstanding of the Association ID Thread-Index: AclJzdNZSY7CnagwTjiuqh0mbygxywAqn7pQAYMWaWA= Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A582BE8@ENFIMBOX1.ad.datcon.co.uk> References: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe> <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4655F3@ENFIMBOX1.ad.datcon.co.uk> <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4B2B5E@ENFIMBOX1.ad.datcon.co.uk> In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4B2B5E@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi all, Following up on this Association ID discussion, I think we're now in sync o= n the technical issues. It is possible to signal both end-to-end and segme= nt protection using association type 1 as defined. However, the usage of t= he Association ID is different in the two cases, resulting in - complex processing rules for ASSOCIATION objects at merge nodes - an overlap in Association ID and LSP ID spaces - a corresponding restriction on the mplsTunnelInstance values available t= o branch nodes. Our proposal (draft-rhodes-ccamp-rsvp-recovery-fix) was to avoid these issu= es by using a different association type for segment recovery. That would = be a non-back-compatible change, and if adopted then existing segment recov= ery implementations would have to be modified. However, I think it also cl= arifies the protocol and could improve interoperability longer term. Does anyone have a strong preference for one option or the other? Or any a= lternatives to propose? Thanks, Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of Nic Neate Sent: 19 November 2008 22:01 To: Aria - Adrian Farrel Personal Cc: ccamp@ops.ietf.org Subject: RE: Clearing up your misunderstanding of the Association ID Hi Adrian, As we discussed earlier, there's also an Association ID / LSP ID space over= lap issue here that's worth drawing out. The branch node is generating ASSOCIATION objects for both end-to-end prote= ction and segment protection, and always uses the same Association Type and= Source. The Association IDs that it chooses must therefore not clash. In= the end-to-end case, the Association ID is actually an LSP ID. Your first= rule for the merge node is to check the Association ID against other segme= nt Association IDs. Therefore, LSP IDs allocated to end-to-end protected L= SPs must not clash with (existing or future) segment Association IDs. LSP IDs are actually allocated by the management tool / MIB interface (mpls= TunnelInstance). I think this therefore amounts to a restriction on the MI= B interface / management tool. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 22:34 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Re: Clearing up your misunderstanding of the Association ID So... Nic and I sat down today and discussed this particluar issue: how to interp= ret the Association ID in a received Path message in order to associate a n= ew LSP with some other LSP at a merge point. There are two cases that arise. If the new LSP is part of a segment protect= ion relationship, the Association ID is a unique "set identifier" in the co= ntext of the Association Source. If the LSP is part of an end-to-end protec= tion relationship, the Association ID identifies the LSP ID of the protecti= on partner. Nic's concern (and he convinced me for a while :-) is that there is an issu= e with distinguishing this case when a segment protection LSP is, itself, p= rotected along its whole path in an end-to-end manner. Having thought about this more, I believe the following processing rules th= at can be applied to make this work. I would be interested in any use cases= (in particular message arrival variants) that anyone believes breaks these= rules. For each Association Object on the received Path message... 1. Look for an existing LSP with association object that matches {Associati= on Source, Association ID} from the new Path message. If found, this is seg= ment protection protecting from the Association Source to this node. Stop. 2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID= } and with LSP ID equal to received Association ID. The Association Source = can (and probably should) also be checked against the sender source address= on the matched LSP. If found, this is end-to-end protection from Associati= on Source to dest. Note that there may be multiple Association objects on a Path message. Note= also, that 4872 requires the use of the same Session specifically to enabl= e the use of the Association ID to LSP ID mapping. As far as I can see, this addresses all cases. Cheers, Adrian ----- Original Message ----- From: "Nic Neate" To: "Aria - Adrian Farrel Personal" Cc: ; "labn - Lou Berger" ; "ALU - Di= mitri Papadimitriou" Sent: Tuesday, November 18, 2008 3:07 PM Subject: RE: Clearing up your misunderstanding of the Association ID Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to = changing the specific procedures defined in 4872 for setting the associatio= n ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873. However, I still have some concerns about interworking of end-to-end and se= gment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try= to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think y= ou may have misread the relevant RFCs. I don't believe any new Association = ID type is needed to achieve the function: we can simply use the 4872 assoc= iation type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that i= n 4873, the context is not end-to-end LSP recovery so the restriction on t= he Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of yo= ur issues go away. Cheers, Adrian From owner-ccamp@ops.ietf.org Thu Nov 27 15:18:30 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 120B83A6A75 for ; Thu, 27 Nov 2008 15:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.093 X-Spam-Level: X-Spam-Status: No, score=-0.093 tagged_above=-999 required=5 tests=[AWL=-1.458, 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 NDSlNXqCcBDR for ; Thu, 27 Nov 2008 15:18:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 388B73A6A1A for ; Thu, 27 Nov 2008 15:18:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L5q1l-0008BJ-Og for ccamp-data@psg.com; Thu, 27 Nov 2008 23:12:05 +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 1L5q1g-0007z1-N4 for ccamp@ops.ietf.org; Thu, 27 Nov 2008 23:12:02 +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 mARNBZuQ026199; Thu, 27 Nov 2008 23:11:35 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 mARNBQXB026189; Thu, 27 Nov 2008 23:11:27 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Young Lee" , "Greg Bernstein" , "Wataru Imajuku" Cc: , "Brungard, Deborah A, ALABS" Subject: Renaming draft-ietf-ccamp-wavelength-switched-framework-01.txt Date: Thu, 27 Nov 2008 23:10:02 -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 editors, As discussed in CCAMP in Minneapolis, this I-D really needs to be renamed to show that it is limited to RWA (just like draft-ietf-ccamp-rwa-info-01.txt Could you please resubmit it as draft-ietf-ccamp-rwa-wson-framework-00.txt Deborah and I will make sure it is flagged as replacing the current I-D. Thanks, Adrian From MAILER-DAEMON Thu Nov 27 20:46:50 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 B00A43A6A7C for ; Thu, 27 Nov 2008 20:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rwonXFZ4YHkN for ; Thu, 27 Nov 2008 20:46:49 -0800 (PST) Received: from smtp10.fiu.edu (smtp10.fiu.edu [131.94.189.203]) by core3.amsl.com (Postfix) with ESMTP id BA64B3A6869 for ; Thu, 27 Nov 2008 20:46:49 -0800 (PST) Received: from localhost (localhost) by smtp10.fiu.edu (MOS 3.8.7a) with internal id LXM75662; Thu, 27 Nov 2008 23:46:46 -0500 (EST) Date: Thu, 27 Nov 2008 23:46:46 -0500 (EST) From: Mail Delivery Subsystem Message-Id: <200811280446.LXM75662@smtp10.fiu.edu> To: ccamp-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="LXM75662.1227847606/smtp10.fiu.edu" Subject: Returned mail: User unknown Auto-Submitted: auto-generated (failure) X-DSN-Junkmail: UCE(300) X-DSN-Junkmail-Status: score=300/40, host=smtp10.fiu.edu This is a MIME-encapsulated message --LXM75662.1227847606/smtp10.fiu.edu The original message was received at Thu, 27 Nov 2008 23:46:45 -0500 (EST) from ekm-dsl-static-61.17.217.60.vsnl.net.in [61.17.217.60] ----- The following addresses had permanent delivery errors ----- ccamp001@fiu.edu --LXM75662.1227847606/smtp10.fiu.edu Content-Type: message/delivery-status Reporting-MTA: dns; smtp10.fiu.edu Arrival-Date: Thu, 27 Nov 2008 23:46:45 -0500 (EST) Final-Recipient: RFC822; ccamp001@fiu.edu Action: failed Status: 5.1.1 Remote-MTA: X-Unix; mirapoint Diagnostic-Code: smtp; 550 5.1.1 User unknown Last-Attempt-Date: Thu, 27 Nov 2008 23:46:46 -0500 (EST) --LXM75662.1227847606/smtp10.fiu.edu Content-Type: message/rfc822 Received: from ekm-dsl-static-61.17.217.60.vsnl.net.in (HELO anuajithkumar) ([61.17.217.60]) by smtp10.fiu.edu (MOS 3.8.7a FastPath queued) with SMTP id LXM75659; Thu, 27 Nov 2008 23:46:45 -0500 (EST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20081128151641.2754.qmail@anuajithkumar> To: Subject: RE: Doctor Alberta From: Date: Thu, 27 Nov 2008 23:46:45 -0500 (EST) X-Junkmail: UCE(300) X-Junkmail-Status: score=300/40, host=smtp10.fiu.edu X-Junkmail-SD-Raw: score=confirmed, refid=str=0001.0A0B0208.492F40E8.0052,ss=4,sh,fgs=0, ip=61.17.217.60, so=2008-05-01 23:44:25, dmn=5.4.3/2008-02-01 X-Junkmail-IWF: false Precedence: bulk --LXM75662.1227847606/smtp10.fiu.edu-- From morganica@alpinahaus.at Fri Nov 28 02:44: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 3AE133A693D for ; Fri, 28 Nov 2008 02:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.833 X-Spam-Level: X-Spam-Status: No, score=-31.833 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FXFIhhCmK4a for ; Fri, 28 Nov 2008 02:44:56 -0800 (PST) Received: from host144-211-static.106-82-b.business.telecomitalia.it (host144-211-static.106-82-b.business.telecomitalia.it [82.106.211.144]) by core3.amsl.com (Postfix) with SMTP id 1C8B23A6B83 for ; Fri, 28 Nov 2008 02:44:54 -0800 (PST) To: Subject: Lord that prick is heroic From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081128104455.1C8B23A6B83@core3.amsl.com> Date: Fri, 28 Nov 2008 02:44:54 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-ccamp@ops.ietf.org Fri Nov 28 11:00:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568163A6939 for ; Fri, 28 Nov 2008 11:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.364 X-Spam-Level: X-Spam-Status: No, score=0.364 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_40=-0.185, 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 pluljFzezveg for ; Fri, 28 Nov 2008 11:00:21 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B60A3A6872 for ; Fri, 28 Nov 2008 11:00:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L68UY-0009QG-Mz for ccamp-data@psg.com; Fri, 28 Nov 2008 18:55:02 +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 1L68UU-0009PJ-8d for ccamp@ops.ietf.org; Fri, 28 Nov 2008 18:55:00 +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 mASIsqAV016898 for ; Fri, 28 Nov 2008 18:54:55 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 mASIsoMt016860 for ; Fri, 28 Nov 2008 18:54:52 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP I-Ds pending last call Date: Fri, 28 Nov 2008 18:54:47 -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, As discussed in Minneapolis, we have quite a long list of I-Ds pending last call (see below). We want to give reasonable time for review of each draft so we need to stagger them. On the other hand, we don't want last calls to go on for ever, so we will do them in batches. Nevertheless, this will probably takes until well into March. So, if you are the author of one of these drafts, please be patient. draft-ietf-ccamp-path-key-ero-02.txt draft-ietf-ccamp-gmpls-mln-extensions-03.txt draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt draft-ietf-ccamp-ethernet-traffic-parameters-06.txt draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt draft-ietf-ccamp-gmpls-ether-svcs-02.txt draft-ietf-ccamp-gmpls-mef-uni-01.txt draft-ietf-ccamp-lsp-hierarchy-bis-05.txt draft-ietf-ccamp-confirm-data-channel-status-02.txt draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt Cheers, Adrian and Deborah From nortet@aeronorte.com.br Sat Nov 29 02:50:23 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 7277A3A6A47 for ; Sat, 29 Nov 2008 02:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.656 X-Spam-Level: X-Spam-Status: No, score=-33.656 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvW193nkAN1A for ; Sat, 29 Nov 2008 02:50:22 -0800 (PST) Received: from ae.wakwak.com (unknown [89.36.175.208]) by core3.amsl.com (Postfix) with SMTP id 87D983A684E for ; Sat, 29 Nov 2008 02:50:20 -0800 (PST) To: Subject: Private Order 62395 From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 0527-2, 07/08/2005), Outbound message X-Antivirus-Status: Clean Message-Id: <20081129105021.87D983A684E@core3.amsl.com> Date: Sat, 29 Nov 2008 02:50:20 -0800 (PST) Click here to view as a webpage.


Windows Live Customer Support | Hotmail Support FAQs | Newsletter feedback

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 As a Windows Live member you have received this e-mail to inform you of updates, changes to the service, or special news and information vital to the service. Our policy is to send e-mail messages only to announce such information, and we'll continue to honor this policy. These communications are required as a part of this service. If you do not wish to receive these letters you may discontinue your participation in the service and close your account.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
From jim.mccrone@airwavesolutions.co.uk Sat Nov 29 08:43: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 0998E3A6A30 for ; Sat, 29 Nov 2008 08:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.744 X-Spam-Level: X-Spam-Status: No, score=-27.744 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6rK6l0IeeW4 for ; Sat, 29 Nov 2008 08:43:15 -0800 (PST) Received: from aic-habitat.com (unknown [189.12.136.78]) by core3.amsl.com (Postfix) with SMTP id 8A40C3A6811 for ; Sat, 29 Nov 2008 08:43:12 -0800 (PST) To: Subject: Private Order 87172 From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 080611-1, 11/06/2008), Outbound message X-Antivirus-Status: Clean Message-Id: <20081129164313.8A40C3A6811@core3.amsl.com> Date: Sat, 29 Nov 2008 08:43:12 -0800 (PST) Click here to view as a webpage.


Windows Live Customer Support | Hotmail Support FAQs | Newsletter feedback

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 As a Windows Live member you have received this e-mail to inform you of updates, changes to the service, or special news and information vital to the service. Our policy is to send e-mail messages only to announce such information, and we'll continue to honor this policy. These communications are required as a part of this service. If you do not wish to receive these letters you may discontinue your participation in the service and close your account.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
From manthieu.cany@alten.co.uk Sun Nov 30 05:00:32 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 0F6043A6956 for ; Sun, 30 Nov 2008 05:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.486 X-Spam-Level: X-Spam-Status: No, score=-17.486 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwv1DxbhzrOM for ; Sun, 30 Nov 2008 05:00:31 -0800 (PST) Received: from 79-100-108-215.btc-net.bg (87-126-58-138.btc-net.bg [87.126.58.138]) by core3.amsl.com (Postfix) with SMTP id 337593A683B for ; Sun, 30 Nov 2008 05:00:29 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081130130030.337593A683B@core3.amsl.com> Date: Sun, 30 Nov 2008 05:00:29 -0800 (PST) Click here to view as a webpage. From janny794@admin.spamcop.net Sun Nov 30 14:40: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 96FB828C164 for ; Sun, 30 Nov 2008 14:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.84 X-Spam-Level: X-Spam-Status: No, score=-7.84 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z3fgCoKrVYS for ; Sun, 30 Nov 2008 14:40:27 -0800 (PST) Received: from 71-221-236-96.dvnp.qwest.net (71-221-236-96.dvnp.qwest.net [71.221.236.96]) by core3.amsl.com (Postfix) with SMTP id 7CC5F28C17B for ; Sun, 30 Nov 2008 14:40:25 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081130224026.7CC5F28C17B@core3.amsl.com> Date: Sun, 30 Nov 2008 14:40:25 -0800 (PST) Click here to view as a webpage. From 2008note2911@gmail.com Sun Nov 30 21:20:19 2008 Return-Path: <2008note2911@gmail.com> 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 38E2A3A68E5 for ; Sun, 30 Nov 2008 21:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPDFe5Kaukvf for ; Sun, 30 Nov 2008 21:20:18 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 467433A67B6 for ; Sun, 30 Nov 2008 21:20:18 -0800 (PST) Received: from localhost ([190.245.9.133]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KB600MZSMT7FR60@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Mon, 01 Dec 2008 02:19:57 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Mon, 01 Dec 2008 03:20:01 +0100 Date: Mon, 01 Dec 2008 03:20:01 +0100 From: "2008note2911@gmail.com" <2008note2911@gmail.com> Subject: COMPUTADORA ATHLON COMPLETA UNICA! ATHLON 5000+ GeForce 6100 To: PC <2008note2911@gmail.com> Message-id: <380-2200812112201859@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII 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 TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B EMail: 2008note2911@gmail=2Ecom -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: ASUS M2NMX SE PLUS chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco r=EDgido: 160 GB SATA2 -Medio optico: ReGrabadora de DVD Hewlett Packard 20X -Placa de red: 10/100 on board -Placa de sonido: 6 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 9024 -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=2E Microsoft Windows XP SP3 -PRECIO $899 FINAL From jimenezmannerdusters@accentdisplay.com Sun Nov 30 21:24:17 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728193A68E5 for ; Sun, 30 Nov 2008 21:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.188 X-Spam-Level: X-Spam-Status: No, score=-28.188 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXOmF0ytioc5 for ; Sun, 30 Nov 2008 21:24:17 -0800 (PST) Received: from agripac.se (unknown [96.39.4.101]) by core3.amsl.com (Postfix) with SMTP id 63E113A68DD for ; Sun, 30 Nov 2008 21:24:15 -0800 (PST) To: Subject: explonation of life's secret code From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201052416.63E113A68DD@core3.amsl.com> Date: Sun, 30 Nov 2008 21:24:15 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Nov 2008 18:56:52 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP I-Ds pending last call Date: Fri, 28 Nov 2008 18:54:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, As discussed in Minneapolis, we have quite a long list of I-Ds pending last call (see below). We want to give reasonable time for review of each draft so we need to stagger them. On the other hand, we don't want last calls to go on for ever, so we will do them in batches. Nevertheless, this will probably takes until well into March. So, if you are the author of one of these drafts, please be patient. draft-ietf-ccamp-path-key-ero-02.txt draft-ietf-ccamp-gmpls-mln-extensions-03.txt draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt draft-ietf-ccamp-ethernet-traffic-parameters-06.txt draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt draft-ietf-ccamp-gmpls-ether-svcs-02.txt draft-ietf-ccamp-gmpls-mef-uni-01.txt draft-ietf-ccamp-lsp-hierarchy-bis-05.txt draft-ietf-ccamp-confirm-data-channel-status-02.txt draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt Cheers, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Nov 2008 23:14:22 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Young Lee" , "Greg Bernstein" , "Wataru Imajuku" Cc: , "Brungard, Deborah A, ALABS" Subject: Renaming draft-ietf-ccamp-wavelength-switched-framework-01.txt Date: Thu, 27 Nov 2008 23:10:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi editors, As discussed in CCAMP in Minneapolis, this I-D really needs to be renamed to show that it is limited to RWA (just like draft-ietf-ccamp-rwa-info-01.txt Could you please resubmit it as draft-ietf-ccamp-rwa-wson-framework-00.txt Deborah and I will make sure it is flagged as replacing the current I-D. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Nov 2008 11:43:34 +0000 From: Nic Neate To: Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" Date: Thu, 27 Nov 2008 11:41:22 +0000 Subject: FW: Clearing up your misunderstanding of the Association ID Thread-Topic: Clearing up your misunderstanding of the Association ID Thread-Index: AclJzdNZSY7CnagwTjiuqh0mbygxywAqn7pQAYMWaWA= Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A582BE8@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi all, Following up on this Association ID discussion, I think we're now in sync o= n the technical issues. It is possible to signal both end-to-end and segme= nt protection using association type 1 as defined. However, the usage of t= he Association ID is different in the two cases, resulting in - complex processing rules for ASSOCIATION objects at merge nodes - an overlap in Association ID and LSP ID spaces - a corresponding restriction on the mplsTunnelInstance values available t= o branch nodes. Our proposal (draft-rhodes-ccamp-rsvp-recovery-fix) was to avoid these issu= es by using a different association type for segment recovery. That would = be a non-back-compatible change, and if adopted then existing segment recov= ery implementations would have to be modified. However, I think it also cl= arifies the protocol and could improve interoperability longer term. Does anyone have a strong preference for one option or the other? Or any a= lternatives to propose? Thanks, Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of Nic Neate Sent: 19 November 2008 22:01 To: Aria - Adrian Farrel Personal Cc: ccamp@ops.ietf.org Subject: RE: Clearing up your misunderstanding of the Association ID Hi Adrian, As we discussed earlier, there's also an Association ID / LSP ID space over= lap issue here that's worth drawing out. The branch node is generating ASSOCIATION objects for both end-to-end prote= ction and segment protection, and always uses the same Association Type and= Source. The Association IDs that it chooses must therefore not clash. In= the end-to-end case, the Association ID is actually an LSP ID. Your first= rule for the merge node is to check the Association ID against other segme= nt Association IDs. Therefore, LSP IDs allocated to end-to-end protected L= SPs must not clash with (existing or future) segment Association IDs. LSP IDs are actually allocated by the management tool / MIB interface (mpls= TunnelInstance). I think this therefore amounts to a restriction on the MI= B interface / management tool. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 22:34 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Re: Clearing up your misunderstanding of the Association ID So... Nic and I sat down today and discussed this particluar issue: how to interp= ret the Association ID in a received Path message in order to associate a n= ew LSP with some other LSP at a merge point. There are two cases that arise. If the new LSP is part of a segment protect= ion relationship, the Association ID is a unique "set identifier" in the co= ntext of the Association Source. If the LSP is part of an end-to-end protec= tion relationship, the Association ID identifies the LSP ID of the protecti= on partner. Nic's concern (and he convinced me for a while :-) is that there is an issu= e with distinguishing this case when a segment protection LSP is, itself, p= rotected along its whole path in an end-to-end manner. Having thought about this more, I believe the following processing rules th= at can be applied to make this work. I would be interested in any use cases= (in particular message arrival variants) that anyone believes breaks these= rules. For each Association Object on the received Path message... 1. Look for an existing LSP with association object that matches {Associati= on Source, Association ID} from the new Path message. If found, this is seg= ment protection protecting from the Association Source to this node. Stop. 2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID= } and with LSP ID equal to received Association ID. The Association Source = can (and probably should) also be checked against the sender source address= on the matched LSP. If found, this is end-to-end protection from Associati= on Source to dest. Note that there may be multiple Association objects on a Path message. Note= also, that 4872 requires the use of the same Session specifically to enabl= e the use of the Association ID to LSP ID mapping. As far as I can see, this addresses all cases. Cheers, Adrian ----- Original Message ----- From: "Nic Neate" To: "Aria - Adrian Farrel Personal" Cc: ; "labn - Lou Berger" ; "ALU - Di= mitri Papadimitriou" Sent: Tuesday, November 18, 2008 3:07 PM Subject: RE: Clearing up your misunderstanding of the Association ID Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to = changing the specific procedures defined in 4872 for setting the associatio= n ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873. However, I still have some concerns about interworking of end-to-end and se= gment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try= to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think y= ou may have misread the relevant RFCs. I don't believe any new Association = ID type is needed to achieve the function: we can simply use the 4872 assoc= iation type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that i= n 4873, the context is not end-to-end LSP recovery so the restriction on t= he Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of yo= ur issues go away. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2008 14:19:35 +0000 Message-ID: <03A5339A999247849861E8DB3D331DB3@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: [OSPF] WG Last Call on draft-ietf-ospf-te-node-addr-05.txt Date: Mon, 24 Nov 2008 14:17:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi CCAMP, This last call in the OSPF working group may be of interest to you. Adrian ----- Original Message ----- From: "Acee Lindem" To: "OSPF List" Sent: Sunday, November 23, 2008 8:09 PM Subject: [OSPF] WG Last Call on draft-ietf-ospf-te-node-addr-05.txt > This starts the WG last for "Advertising a Router's Local Addresses > in OSPF TE Extensions" - draft-ietf-ospf-te-node-addr-05.txt. It will > conclude on Monday, December 8th, 2008 at 12:00 AM. > > This document was previously WG last called about 2 years back. We > delayed advancing it in our to align with the ASON requirements. With > the addition of the IPv4 and IPv6 prefix length, we now feel it will > be usable for ASCON as well. > > Thanks, > Acee & Abhay > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2008 15:50:51 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Loa Andersson" Subject: working group last call on MPLS and GMPLS security framework Date: Fri, 21 Nov 2008 15:48:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit The MPLS working group is holding a last call on this draft. It is very important that you review it and comment. Please send comments to the MPLS list if you are subscribed. Otherwise then them to CCAMP and I will forward them. Thanks, Adrian ----- Original Message ----- From: "Loa Andersson" To: Cc: "Ross Callon" ; "David Ward" Sent: Friday, November 21, 2008 2:58 PM Subject: [mpls] working group last call on MPLS and GMPLS security framework > Working Group, > > this is to start a two week working group last call on: > > Security Framework for MPLS and GMPLS Networks > draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt > > please send your comments to the working group mailing list or > directly to the wg co-chairs. > > This working group last will end EOB Fri Dec 5 2008. > > Loa and Geoge > > -- > > > Loa Andersson > > Sr Strategy and Standards Manager > Redback Networks phone: +46 8 632 77 14 > An Ericsson company > email: > loa.andersson@redback.com > loa@pi.nu > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2008 00:39:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt Date: Thu, 20 Nov 2008 19:36:00 -0500 Message-ID: Thread-Topic: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt Thread-Index: AclLcSBkC9PN1RWSRrquCv8jL/wuaA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-02.txt Please send your comments to the mailing list prior to EOB Dec 5. Thanks, Deborah and Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Nov 2008 22:03:02 +0000 From: Nic Neate To: Aria - Adrian Farrel Personal CC: "ccamp@ops.ietf.org" Date: Wed, 19 Nov 2008 22:00:49 +0000 Subject: RE: Clearing up your misunderstanding of the Association ID Thread-Topic: Clearing up your misunderstanding of the Association ID Thread-Index: AclJzdNZSY7CnagwTjiuqh0mbygxywAqn7pQ Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4B2B5E@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Adrian, As we discussed earlier, there's also an Association ID / LSP ID space over= lap issue here that's worth drawing out. The branch node is generating ASSOCIATION objects for both end-to-end prote= ction and segment protection, and always uses the same Association Type and= Source. The Association IDs that it chooses must therefore not clash. In= the end-to-end case, the Association ID is actually an LSP ID. Your first= rule for the merge node is to check the Association ID against other segme= nt Association IDs. Therefore, LSP IDs allocated to end-to-end protected L= SPs must not clash with (existing or future) segment Association IDs. LSP IDs are actually allocated by the management tool / MIB interface (mpls= TunnelInstance). I think this therefore amounts to a restriction on the MI= B interface / management tool. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 22:34 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Re: Clearing up your misunderstanding of the Association ID So... Nic and I sat down today and discussed this particluar issue: how to interp= ret the Association ID in a received Path message in order to associate a n= ew LSP with some other LSP at a merge point. There are two cases that arise. If the new LSP is part of a segment protect= ion relationship, the Association ID is a unique "set identifier" in the co= ntext of the Association Source. If the LSP is part of an end-to-end protec= tion relationship, the Association ID identifies the LSP ID of the protecti= on partner. Nic's concern (and he convinced me for a while :-) is that there is an issu= e with distinguishing this case when a segment protection LSP is, itself, p= rotected along its whole path in an end-to-end manner. Having thought about this more, I believe the following processing rules th= at can be applied to make this work. I would be interested in any use cases= (in particular message arrival variants) that anyone believes breaks these= rules. For each Association Object on the received Path message... 1. Look for an existing LSP with association object that matches {Associati= on Source, Association ID} from the new Path message. If found, this is seg= ment protection protecting from the Association Source to this node. Stop. 2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID= } and with LSP ID equal to received Association ID. The Association Source = can (and probably should) also be checked against the sender source address= on the matched LSP. If found, this is end-to-end protection from Associati= on Source to dest. Note that there may be multiple Association objects on a Path message. Note= also, that 4872 requires the use of the same Session specifically to enabl= e the use of the Association ID to LSP ID mapping. As far as I can see, this addresses all cases. Cheers, Adrian ----- Original Message ----- From: "Nic Neate" To: "Aria - Adrian Farrel Personal" Cc: ; "labn - Lou Berger" ; "ALU - Di= mitri Papadimitriou" Sent: Tuesday, November 18, 2008 3:07 PM Subject: RE: Clearing up your misunderstanding of the Association ID Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to = changing the specific procedures defined in 4872 for setting the associatio= n ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873. However, I still have some concerns about interworking of end-to-end and se= gment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try= to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think y= ou may have misread the relevant RFCs. I don't believe any new Association = ID type is needed to achieve the function: we can simply use the 4872 assoc= iation type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that i= n 4873, the context is not end-to-end LSP recovery so the restriction on t= he Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of yo= ur issues go away. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 22:35:42 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Nic Neate" Cc: Subject: Re: Clearing up your misunderstanding of the Association ID Date: Tue, 18 Nov 2008 22:34:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit So... Nic and I sat down today and discussed this particluar issue: how to interpret the Association ID in a received Path message in order to associate a new LSP with some other LSP at a merge point. There are two cases that arise. If the new LSP is part of a segment protection relationship, the Association ID is a unique "set identifier" in the context of the Association Source. If the LSP is part of an end-to-end protection relationship, the Association ID identifies the LSP ID of the protection partner. Nic's concern (and he convinced me for a while :-) is that there is an issue with distinguishing this case when a segment protection LSP is, itself, protected along its whole path in an end-to-end manner. Having thought about this more, I believe the following processing rules that can be applied to make this work. I would be interested in any use cases (in particular message arrival variants) that anyone believes breaks these rules. For each Association Object on the received Path message... 1. Look for an existing LSP with association object that matches {Association Source, Association ID} from the new Path message. If found, this is segment protection protecting from the Association Source to this node. Stop. 2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID} and with LSP ID equal to received Association ID. The Association Source can (and probably should) also be checked against the sender source address on the matched LSP. If found, this is end-to-end protection from Association Source to dest. Note that there may be multiple Association objects on a Path message. Note also, that 4872 requires the use of the same Session specifically to enable the use of the Association ID to LSP ID mapping. As far as I can see, this addresses all cases. Cheers, Adrian ----- Original Message ----- From: "Nic Neate" To: "Aria - Adrian Farrel Personal" Cc: ; "labn - Lou Berger" ; "ALU - Dimitri Papadimitriou" Sent: Tuesday, November 18, 2008 3:07 PM Subject: RE: Clearing up your misunderstanding of the Association ID Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to changing the specific procedures defined in 4872 for setting the association ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873. However, I still have some concerns about interworking of end-to-end and segment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think you may have misread the relevant RFCs. I don't believe any new Association ID type is needed to achieve the function: we can simply use the 4872 association type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that in 4873, the context is not end-to-end LSP recovery so the restriction on the Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of your issues go away. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 18:37:55 +0000 Message-ID: <49230B3F.9010405@grotto-networking.com> Date: Tue, 18 Nov 2008 12:36:47 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp Subject: VCAT/LCAS draft update... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object from the MLN extensions draft. We define a new VCAT TLV for use in the aforementioned object. All procedures and encodings otherwise are the same as the previous draft. Note that the draft will now be contingent on the MLN extensions draft moving forward. A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.txt Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 17:16:28 +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-vcat-lcas-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081118171501.63DCF28C1F1@core3.amsl.com> Date: Tue, 18 Nov 2008 09:15:01 -0800 (PST) --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 : Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-gmpls-vcat-lcas-06.txt Pages : 22 Date : 2008-11-18 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-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-vcat-lcas-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-18090328.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 16:23:13 +0000 Message-ID: <4922EBC1.3060801@grotto-networking.com> Date: Tue, 18 Nov 2008 10:22:25 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 CC: ccamp Subject: Re: Materials for Semi-Formal WSON meeting today... Content-Type: multipart/alternative; boundary="------------050608080100010602030803" This is a multi-part message in MIME format. --------------050608080100010602030803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Whoops, sorry about that, I meant "semi-*informal*". This is not an IETF meeting, but an somewhat organized meeting of co-authors and interested parties. Thanks Greg Adrian Farrel wrote: > Hi Greg, > > Thanks for taking care of this. > > Just for the record... > > The meeting isn't really "semi-formal." That is, it is not an IETF > meeting, but a meeting of co-authors and interested parties. > > Cheers, > Adrian > ----- Original Message ----- From: "Greg Bernstein" > > To: "Wson (E-mail)" ; "ccamp" > > Sent: Tuesday, November 18, 2008 3:54 PM > Subject: Materials for Semi-Formal WSON meeting today... > > >> Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in >> the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON >> discussion session. >> When I last checked this room was set up in "meeting room" >> configuration, that is, everyone around a big table. This is good for >> discussion but there wasn't a projector. Some of the slides we were >> going to use are: >> >> Existing optical draft discussion: >> http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt >> >> >> Optical Impairment: >> http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt >> >> http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt >> >> >> Please download these so you can follow along. Others with slides, >> please let folks know where to get them so folks can follow along on >> their laptops. >> >> Also, I highly recommend that folks go to the ITU-T web page for the G >> series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup >> the PDFs for *G.671* (characteristics of optical components and >> subsystems), *G.680* (transfer functions of optical networks elements), >> and *G.697* (optical monitoring). No excuses! these are free and you >> should have these if you are interested in optical impairments. >> >> Regards >> >> Greg >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050608080100010602030803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Whoops, sorry about that, I meant "semi-informal". This is not an IETF meeting, but an somewhat organized meeting of co-authors and interested parties.

Thanks

Greg

Adrian Farrel wrote:
Hi Greg,

Thanks for taking care of this.

Just for the record...

The meeting isn't really "semi-formal." That is, it is not an IETF meeting, but a meeting of co-authors and interested parties.

Cheers,
Adrian
----- Original Message ----- From: "Greg Bernstein" <gregb@grotto-networking.com>
To: "Wson (E-mail)" <wson@grotto-networking.com>; "ccamp" <ccamp@ops.ietf.org>
Sent: Tuesday, November 18, 2008 3:54 PM
Subject: Materials for Semi-Formal WSON meeting today...


Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in
the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON
discussion session.
When I last checked this room was set up in "meeting room"
configuration, that is, everyone around a big table. This is good for
discussion but there wasn't a projector. Some of the slides we were
going to use are:

Existing optical draft discussion:
http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt

Optical Impairment:
http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt
http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt

Please download these so you can follow along. Others with slides,
please let folks know where to get them so folks can follow along on
their laptops.

Also, I  highly recommend that folks go to the ITU-T web page for the G
series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup
the PDFs for *G.671* (characteristics of optical components and
subsystems), *G.680* (transfer functions of optical networks elements),
and *G.697* (optical monitoring). No excuses! these are free and you
should have these if you are interested in optical impairments.

Regards

Greg

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237 






-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050608080100010602030803-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 16:09:24 +0000 Message-ID: <141ADD61D0FD4515B7D0C382666267D7@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Greg Bernstein" , "Wson \(E-mail\)" , "ccamp" Subject: Re: Materials for Semi-Formal WSON meeting today... Date: Tue, 18 Nov 2008 16:08:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Greg, Thanks for taking care of this. Just for the record... The meeting isn't really "semi-formal." That is, it is not an IETF meeting, but a meeting of co-authors and interested parties. Cheers, Adrian ----- Original Message ----- From: "Greg Bernstein" To: "Wson (E-mail)" ; "ccamp" Sent: Tuesday, November 18, 2008 3:54 PM Subject: Materials for Semi-Formal WSON meeting today... > Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in > the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON > discussion session. > When I last checked this room was set up in "meeting room" > configuration, that is, everyone around a big table. This is good for > discussion but there wasn't a projector. Some of the slides we were > going to use are: > > Existing optical draft discussion: > http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt > > Optical Impairment: > http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt > http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt > > Please download these so you can follow along. Others with slides, > please let folks know where to get them so folks can follow along on > their laptops. > > Also, I highly recommend that folks go to the ITU-T web page for the G > series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup > the PDFs for *G.671* (characteristics of optical components and > subsystems), *G.680* (transfer functions of optical networks elements), > and *G.697* (optical monitoring). No excuses! these are free and you > should have these if you are interested in optical impairments. > > Regards > > Greg > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 16:07:41 +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=eyudLN17gDzm7hAuW9EItqjXdS7+IyoZbUY1DRR7kw+N+oNWWoMlYM/+VLWO0OtxExURZlUNVEJ4a6sRjjJAiNwWq479v2v6TK2Rvwa1ftasPH2JBPVYR27eawmwx6Us; Date: Tue, 18 Nov 2008 11:05:16 -0600 To: Nic Neate From: Lou Berger Subject: RE: Agenda updated Cc: Lou Berger , "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" , ALU - Dimitri Papadimitriou Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Nic, See below. At 08:06 AM 11/18/2008, Nic Neate wrote: >Hi Lou, > >Following up on our conversation in CCAMP. > >I think you agreed that the "Resource Sharing" association type 2 is >not relevant to this discussion. > >You also said that the intent of the statement from 3.2.1 >"processing and identification occur with respect to segment >recovery LSPs" is to indicate that the procedures defined in RFC >4872 for setting the association ID to an LSP ID are not >used. Instead, a unique identifier should be chosen by the >association source (as suggested in our draft). > >I find this quite a stretch, and think a clarification would improve >the chances of interoperability. As you know, in there's always opportunity for more detailed discussion in any document and that there will always be someone who doesn't understand the more detailed explanation. It's up to the author's and the WG to agree that a draft is sufficient. At the time the document was written, we did. I accept that more language could be helpful to those new to segment recovery. As I suggested to you, I believe the proper way to address this (and to ask for and to get formal clarification) is to open an Errata. >I'm also concerned with the reuse of association type 1 with >different semantics in segment recovery to those defined for >end-to-end recovery. How are the semantics different? Per RFC4872: 16.1. Format The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) has the format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Association Type: 16 bits Indicates the type of association being identified. Note that this value is considered when determining association. The following are values defined in this document. Value Type ----- ---- 0 Reserved 1 Recovery (R) Association ID: 16 bits A value assigned by the LSP head-end. When combined with the Association Type and Association Source, this value uniquely identifies an association. Association Source: 4 or 16 bytes An IPv4 or IPv6 address, respectively, that is associated to the node that originated the association. And RFC4873 says: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP. >Consider the case where a segment recovery LSP is itself end-to-end >protected. Then there will be two type 1 association objects, and >the merge node must process each differently. yes, as is explicity stated in the RFC. >How does the implementation you mentioned decide which is which? What protocol question are you asking here? If you want to see code, most folks don't make that available or charge a fee (I know of some sources of such code, and can provide this info offline if you'd like). >You also dismissed the other issues raised in >draft-rhodes-rsvp-recovery-signaling relating to protection of >recovery LSPs and overlaping protection. Per RFC4873: Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path, e.g., node E shown above. There is no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID. Values for these fields are selected normally, including consideration for the make-before- break concept (as described in [RFC3209]). Intermediate nodes follow standard signaling procedures when processing segment recovery LSPs. A segment recovery LSP may be protected itself using segment or end- to-end protection/restoration. Note, in PSC environments, it may be desirable to construct the Sender_Template and Session objects per [RFC4090]. When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872]. The ASSOCIATION object is used to associate recovery LSPs with the LSP they are protecting. >Please could you respond on the specific technical points raised in the draft? I suggest bringing points you'd like to discuss to the list. Although, I think resolution of the basic understanding of segment recovery is needed to move the discussion further. Again, I suggest filing the errata... Lou >I'd be glad to meet up and discuss this in person while we're in Minneapolis. > >Thanks, > >Nic > > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of labn - Lou Berger >Sent: 16 November 2008 22:46 >To: Nic Neate >Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian >Farrel Personal; ccamp@ops.ietf.org; ALU - Dimitri Papadimitriou >Subject: RE: Agenda updated > >I agree with Dimitri. > >also, note: > > 3.2.1. Recovery Type Processing > > Recovery type processing procedures are the same as those defined in > [RFC4872], but processing and identification occur with respect to > segment recovery LSPs. > >Lou > >At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: > >nick, > > > >you mention: > > > >"3.1 Association between LSPs in different sessions > > > > Segment recovery protecting LSPs may have a different endpoint > > address from the corresponding protected LSP. The protected and > > protecting LSPs are therefore in different Sessions. The Association > > object of type 1 (recovery) is not effective in this case, as the > > Association ID can only associate to an LSP ID within the same > > Session." > > > >but segment recovery makes use of: > > > >"9.1. New Association Type Assignment > > > > > > IANA has made the following assignment to the "Association Types" > > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > > "RSVP PARAMETERS" registry located at > > http://www.iana.org/assignments/rsvp-parameters. > > > > Value Type > > ----- ---- > > 2 Resource Sharing (R) [RFC4873]" > > > >and states: > > > >"Consider the following topology: > > > > A---B---C---D---E---F > > \ / > > G---I > > > > In this topology, end-to-end protection and recovery is not possible > > for an LSP going between node A and node F, but it is possible to > > protect/recover a portion of the LSP. Specifically, if the LSP uses > > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > > can be established along the path [C,G,I,E]." > > > >[...] > > > >"Segment protection or restoration is signaled using a working LSP and > > one or more segment recovery LSPs. Each segment recovery LSP is > > signaled as an independent LSP. Specifically, the Sender_Template > > object uses the IP address of the node originating the recovery path, > > e.g., node C in the topology shown above, and the Session object > > contains the IP address of the node terminating the recovery path, > > e.g., node E shown above. There is no specific requirement on LSP ID > > value, Tunnel ID, and Extended Tunnel ID." > > > >so where is the issue ? > > > >-d. > > > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Friday, November 14, 2008 4:46 PM > > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > > Dimitri; Aria - Adrian Farrel Personal > > > Cc: ccamp@ops.ietf.org > > > Subject: FW: Agenda updated > > > > > > RFC 4873 authors, > > > > > > Just wanted to flag that I'm presenting a problem in segment > > > recovery signaling on Monday, together with a suggested solution. > > > > > > Problem statement: > > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > > Suggested fix: > > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > > > > Nic > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian Farrel > > > Personal > > > Sent: 07 November 2008 19:29 > > > To: ccamp@ops.ietf.org > > > Subject: Agenda updated > > > > > > I have made some updates. > > > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > > > Please shout if there further issues. > > > > > > Thanks, > > > Adrian > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 15:55:46 +0000 Message-ID: <4922E533.6010400@grotto-networking.com> Date: Tue, 18 Nov 2008 09:54:27 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Wson (E-mail)" , ccamp Subject: Materials for Semi-Formal WSON meeting today... Content-Type: multipart/alternative; boundary="------------070600070603090202080004" This is a multi-part message in MIME format. --------------070600070603090202080004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON discussion session. When I last checked this room was set up in "meeting room" configuration, that is, everyone around a big table. This is good for discussion but there wasn't a projector. Some of the slides we were going to use are: Existing optical draft discussion: http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt Optical Impairment: http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt Please download these so you can follow along. Others with slides, please let folks know where to get them so folks can follow along on their laptops. Also, I highly recommend that folks go to the ITU-T web page for the G series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup the PDFs for *G.671* (characteristics of optical components and subsystems), *G.680* (transfer functions of optical networks elements), and *G.697* (optical monitoring). No excuses! these are free and you should have these if you are interested in optical impairments. Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------070600070603090202080004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks interested in WSON in Minneapolis, we've got the Ramsey Room in the Hilton, Tuesday (today) from 3:20PM-5:20PM for our extra WSON discussion session.
When I last checked this room was set up in "meeting room" configuration, that is, everyone around a big table. This is good for discussion but there wasn't a projector. Some of the slides we were going to use are:

Existing optical draft discussion:
http://www.grotto-networking.com/sites/default/files/WSON-Extra-Meeting-Minneapolis-Nov-2008_0.ppt

Optical Impairment:
http://www.grotto-networking.com/sites/default/files/WSON-impairments-CCAMP-MinneapolisV2.ppt
http://www.grotto-networking.com/sites/default/files/WSON-impairments-info%20CCAMP-IETF-73-V2.ppt

Please download these so you can follow along. Others with slides, please let folks know where to get them so folks can follow along on their laptops.

Also, I  highly recommend that folks go to the ITU-T web page for the G series of recommendations http://www.itu.int/rec/T-REC-G/e and pickup the PDFs for G.671 (characteristics of optical components and subsystems), G.680 (transfer functions of optical networks elements), and G.697 (optical monitoring). No excuses! these are free and you should have these if you are interested in optical impairments.

Regards

Greg
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------070600070603090202080004-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 15:08:04 +0000 From: Nic Neate To: Aria - Adrian Farrel Personal CC: "ccamp@ops.ietf.org" , labn - Lou Berger , ALU - Dimitri Papadimitriou Date: Tue, 18 Nov 2008 15:07:36 +0000 Subject: RE: Clearing up your misunderstanding of the Association ID Thread-Topic: Clearing up your misunderstanding of the Association ID Thread-Index: AclJhfbNLbyZOjCkQsmXDXM+Gp8/+QACLLEg Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4655F3@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Thanks Adrian, I think the key source of confusion is that RFC 4873 makes no reference to = changing the specific procedures defined in 4872 for setting the associatio= n ID to the LSP ID of the protecting/protected LSP. For example, in section 5.1: 5.1. Identifiers ... To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. Your email and discussion with Lou has helped expain the intention of 4873.= However, I still have some concerns about interworking of end-to-end and = segment recovery - see my email to Lou. Nic -----Original Message----- From: Aria - Adrian Farrel Personal Sent: 18 November 2008 14:00 To: Nic Neate Cc: ccamp@ops.ietf.org Subject: Clearing up your misunderstanding of the Association ID Hi Nic, I think there are a bunch of issues that you are raising, and we should try= to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think y= ou may have misread the relevant RFCs. I don't believe any new Association = ID type is needed to achieve the function: we can simply use the 4872 assoc= iation type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that i= n 4873, the context is not end-to-end LSP recovery so the restriction on t= he Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of yo= ur issues go away. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 15:02:38 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)' to Experimental RFC Message-Id: <20081118150114.317F13A688F@core3.amsl.com> Date: Tue, 18 Nov 2008 07:01:14 -0800 (PST) The IESG has approved the following document: - 'GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) ' as an Experimental RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt Technical Summary This experimental document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. Working Group Summary No controversy reported. These protocol extensions have full support of the working group, but are being submitted as experimental because there is no immediate intention to build or deploy product containing these features. See PROTO writeup by Adrian Farrel (posted to the tracker by Amy Vezza). Document Quality No existing implementations. No announced plans. The document has had ample review for a experimental straightforward extension to an existing protocol. An alternate approach that was considered, along with the reason that it was not selected, is discussed in an Appendix. Personnel Adrian Farrel is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 14:16:59 +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: Agenda updated Date: Tue, 18 Nov 2008 15:16:02 +0100 Message-ID: <00275A5B436CA441900CB10936742A380161D40C@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Agenda updated Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAA3sOeAABq6O2A= From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , "labn - Lou Berger" Cc: , "Aria - Adrian Farrel Personal" , hi nic, my 2 cents here below:=20 > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Tuesday, November 18, 2008 3:07 PM > To: labn - Lou Berger > Cc: IBryskin@advaoptical.com; Aria - Adrian Farrel Personal;=20 > ccamp@ops.ietf.org; PAPADIMITRIOU Dimitri > Subject: RE: Agenda updated >=20 > Hi Lou, >=20 > Following up on our conversation in CCAMP. >=20 > I think you agreed that the "Resource Sharing" association=20 > type 2 is not relevant to this discussion. >=20 > You also said that the intent of the statement from 3.2.1=20 > "processing and identification occur with respect to segment=20 > recovery LSPs" is to indicate that the procedures defined in=20 > RFC 4872 for setting the association ID to an LSP ID are not=20 > used. Instead, a unique identifier should be chosen by the=20 > association source (as suggested in our draft). >=20 > I find this quite a stretch, and think a clarification would=20 > improve the chances of interoperability. where is the stretch ? in end-to-end the source of the tunnel is the source of the association whereas in the segment case they are not the same. > I'm also concerned with the reuse of association type 1 with=20 > different semantics in segment recovery to those defined for=20 > end-to-end recovery. Consider the case where a segment=20 > recovery LSP is itself end-to-end protected. =20 what does this actually mean ? does it refer to the case where there are two 2 protecting segments ? > Then there will=20 > be two type 1 association objects, and the merge node must=20 > process each differently. How does the implementation you=20 > mentioned decide which is which? > > You also dismissed the other issues raised in=20 > draft-rhodes-rsvp-recovery-signaling relating to protection=20 > of recovery LSPs and overlaping protection. Please could you=20 > respond on the specific technical points raised in the draft? it is the same as the base case, if a segment recovery LSP is himself protected partially the source of the association will not be the source of protected recovery segment. =20 thanks, -d. > I'd be glad to meet up and discuss this in person while we're=20 > in Minneapolis. >=20 > Thanks, >=20 > Nic >=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of labn - Lou Berger > Sent: 16 November 2008 22:46 > To: Nic Neate > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal; ccamp@ops.ietf.org; ALU - Dimitri=20 > Papadimitriou > Subject: RE: Agenda updated >=20 > I agree with Dimitri. >=20 > also, note: >=20 > 3.2.1. Recovery Type Processing >=20 > Recovery type processing procedures are the same as those=20 > defined in > [RFC4872], but processing and identification occur with respect to > segment recovery LSPs. >=20 > Lou >=20 > At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: > >nick, > > > >you mention: > > > >"3.1 Association between LSPs in different sessions > > > > Segment recovery protecting LSPs may have a different endpoint > > address from the corresponding protected LSP. The protected and > > protecting LSPs are therefore in different Sessions. =20 > The Association > > object of type 1 (recovery) is not effective in this case, as the > > Association ID can only associate to an LSP ID within the same > > Session." > > > >but segment recovery makes use of: > > > >"9.1. New Association Type Assignment > > > > > > IANA has made the following assignment to the "Association Types" > > Registry (see [RFC4872]) in the "ASSOCIATION (object)"=20 > section of the > > "RSVP PARAMETERS" registry located at > > http://www.iana.org/assignments/rsvp-parameters. > > > > Value Type > > ----- ---- > > 2 Resource Sharing (R) [RFC4873]" > > > >and states: > > > >"Consider the following topology: > > > > A---B---C---D---E---F > > \ / > > G---I > > > > In this topology, end-to-end protection and recovery is=20 > not possible > > for an LSP going between node A and node F, but it is possible to > > protect/recover a portion of the LSP. Specifically, if=20 > the LSP uses > > a working path of [A,B,C,D,E,F], then a protection or=20 > restoration LSP > > can be established along the path [C,G,I,E]." > > > >[...] > > > >"Segment protection or restoration is signaled using a=20 > working LSP and > > one or more segment recovery LSPs. Each segment recovery LSP is > > signaled as an independent LSP. Specifically, the=20 > Sender_Template > > object uses the IP address of the node originating the=20 > recovery path, > > e.g., node C in the topology shown above, and the Session object > > contains the IP address of the node terminating the=20 > recovery path, > > e.g., node E shown above. There is no specific=20 > requirement on LSP ID > > value, Tunnel ID, and Extended Tunnel ID." > > > >so where is the issue ? > > > >-d. > > > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Friday, November 14, 2008 4:46 PM > > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > > Dimitri; Aria - Adrian Farrel Personal > > > Cc: ccamp@ops.ietf.org > > > Subject: FW: Agenda updated > > > > > > RFC 4873 authors, > > > > > > Just wanted to flag that I'm presenting a problem in segment > > > recovery signaling on Monday, together with a suggested solution. > > > > > > Problem statement: > > >=20 > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > > Suggested fix: > > >=20 > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > > > > Nic > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria -=20 > Adrian Farrel > > > Personal > > > Sent: 07 November 2008 19:29 > > > To: ccamp@ops.ietf.org > > > Subject: Agenda updated > > > > > > I have made some updates. > > > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > > > Please shout if there further issues. > > > > > > Thanks, > > > Adrian > > > > > > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 14:07:04 +0000 From: Nic Neate To: labn - Lou Berger CC: "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" , ALU - Dimitri Papadimitriou Date: Tue, 18 Nov 2008 14:06:34 +0000 Subject: RE: Agenda updated Thread-Topic: Agenda updated Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAA3sOeA Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Lou, Following up on our conversation in CCAMP. I think you agreed that the "Resource Sharing" association type 2 is not re= levant to this discussion. You also said that the intent of the statement from 3.2.1 "processing and i= dentification occur with respect to segment recovery LSPs" is to indicate t= hat the procedures defined in RFC 4872 for setting the association ID to an= LSP ID are not used. Instead, a unique identifier should be chosen by the= association source (as suggested in our draft). I find this quite a stretch, and think a clarification would improve the ch= ances of interoperability. I'm also concerned with the reuse of association type 1 with different sema= ntics in segment recovery to those defined for end-to-end recovery. Consid= er the case where a segment recovery LSP is itself end-to-end protected. T= hen there will be two type 1 association objects, and the merge node must p= rocess each differently. How does the implementation you mentioned decide = which is which? You also dismissed the other issues raised in draft-rhodes-rsvp-recovery-si= gnaling relating to protection of recovery LSPs and overlaping protection. = Please could you respond on the specific technical points raised in the dr= aft? I'd be glad to meet up and discuss this in person while we're in Minneapoli= s. Thanks, Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of labn - Lou Berger Sent: 16 November 2008 22:46 To: Nic Neate Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Perso= nal; ccamp@ops.ietf.org; ALU - Dimitri Papadimitriou Subject: RE: Agenda updated I agree with Dimitri. also, note: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Lou At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: >nick, > >you mention: > >"3.1 Association between LSPs in different sessions > > Segment recovery protecting LSPs may have a different endpoint > address from the corresponding protected LSP. The protected and > protecting LSPs are therefore in different Sessions. The Association > object of type 1 (recovery) is not effective in this case, as the > Association ID can only associate to an LSP ID within the same > Session." > >but segment recovery makes use of: > >"9.1. New Association Type Assignment > > > IANA has made the following assignment to the "Association Types" > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > "RSVP PARAMETERS" registry located at > http://www.iana.org/assignments/rsvp-parameters. > > Value Type > ----- ---- > 2 Resource Sharing (R) [RFC4873]" > >and states: > >"Consider the following topology: > > A---B---C---D---E---F > \ / > G---I > > In this topology, end-to-end protection and recovery is not possible > for an LSP going between node A and node F, but it is possible to > protect/recover a portion of the LSP. Specifically, if the LSP uses > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > can be established along the path [C,G,I,E]." > >[...] > >"Segment protection or restoration is signaled using a working LSP and > one or more segment recovery LSPs. Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path, > e.g., node E shown above. There is no specific requirement on LSP ID > value, Tunnel ID, and Extended Tunnel ID." > >so where is the issue ? > >-d. > > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, November 14, 2008 4:46 PM > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > Dimitri; Aria - Adrian Farrel Personal > > Cc: ccamp@ops.ietf.org > > Subject: FW: Agenda updated > > > > RFC 4873 authors, > > > > Just wanted to flag that I'm presenting a problem in segment > > recovery signaling on Monday, together with a suggested solution. > > > > Problem statement: > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > Suggested fix: > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > Nic > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian Farrel > > Personal > > Sent: 07 November 2008 19:29 > > To: ccamp@ops.ietf.org > > Subject: Agenda updated > > > > I have made some updates. > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > Please shout if there further issues. > > > > Thanks, > > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 14:01:20 +0000 Message-ID: <020938B8234C48209399F0FF21BD4C31@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Nic Neate" Cc: Subject: Clearing up your misunderstanding of the Association ID Date: Tue, 18 Nov 2008 13:59:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Nic, I think there are a bunch of issues that you are raising, and we should try to itemise them to make sure we close them all off. For the issue of the use of Association ID in segment protection, I think you may have misread the relevant RFCs. I don't believe any new Association ID type is needed to achieve the function: we can simply use the 4872 association type. Section 4.3 of 4872 says... The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP. That gives us the basis of everything we need. Then, in Section 16... The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. I suspect that this is the source of your misunderstanding. But note that in 4873, the context is not end-to-end LSP recovery so the restriction on the Tunnel ID does not apply. If you follow this through now, I suspect you will discover that most of your issues go away. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2008 13:00:25 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Did anyone listen to CCAMP on audio streaming? Date: Tue, 18 Nov 2008 12:58:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Can you drop me an email so we can find out how it sounded. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 22:24:19 +0000 Message-ID: <79713195F7CF4AF99120D6E9672D586F@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Michael H. Behringer" , "Francois Le Faucheur" Subject: Soliciting feedback ondraft-ietf-tsvwg-rsvp-security-groupkeying Date: Mon, 17 Nov 2008 22:22:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi CCAMP, The TSVWG is doing work on group keys for RSVP. These might also be applicable to GMPLS/RSVP-TE so please review the draft (specifically section 5) and send comments to the author (Michael Behringer ) and to the CCAMP list (and preferably the TSVWG list as well). http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/ Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 19:31:14 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081117193001.A7C2B3A6A1F@core3.amsl.com> Date: Mon, 17 Nov 2008 11:30:01 -0800 (PST) --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 Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt Pages : 15 Date : 2008-11-17 This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-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-asymm-bw-bidir-lsps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-17111812.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 15:46:55 +0000 Message-ID: <4921919A.1020707@grotto-networking.com> Date: Mon, 17 Nov 2008 09:45:30 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp Subject: Informal WSON discussion meeting... Content-Type: multipart/alternative; boundary="------------050503050002070708070803" This is a multi-part message in MIME format. --------------050503050002070708070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton). Discussion Topics may include: (a) WSON Framework and RWA Information model document contents and structure * (b) Wavelength converter pool model for use in path computation (c) Signaling extensions -- other uses of wavelength set metric (d) Optical Impairments and the control plane * It is assumed that everyone attending will have *read all the related drafts*. Also this discussion section probably isn't recommended for "tourists". Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050503050002070708070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:
(a) WSON Framework and RWA Information model document contents and structure *
(b) Wavelength converter pool model for use in path computation
(c) Signaling extensions -- other uses of wavelength set metric
(d) Optical Impairments and the control plane  *

It is assumed that everyone attending will have read all the related drafts. Also this discussion section probably isn't recommended for "tourists".

Regards

Greg
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050503050002070708070803-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 15:46:46 +0000 Message-ID: <49219183.5010707@grotto-networking.com> Date: Mon, 17 Nov 2008 09:45:07 -0600 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ccamp Subject: Informal WSON discussion meeting... Content-Type: multipart/alternative; boundary="------------000507000806090106010203" This is a multi-part message in MIME format. --------------000507000806090106010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton). Discussion Topics may include: (a) WSON Framework and RWA Information model document contents and structure * (b) Wavelength converter pool model for use in path computation (c) Signaling extensions -- other uses of wavelength set metric (d) Optical Impairments and the control plane * It is assumed that everyone attending will have *read all the related drafts*. Also this discussion section probably isn't recommended for "tourists". Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------000507000806090106010203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers, wavelength switched optical networks (WSON) are very interesting from both a technical and organizational standpoint (multiple SDOs are involved) . To promote better understanding, there will be a semi-informal WSON meeting on Tuesday from 3:20-5:20PM in the Ramsey conference room (2nd floor of the Hilton).

Discussion Topics may include:
(a) WSON Framework and RWA Information model document contents and structure *
(b) Wavelength converter pool model for use in path computation
(c) Signaling extensions -- other uses of wavelength set metric
(d) Optical Impairments and the control plane  *

It is assumed that everyone attending will have read all the related drafts. Also this discussion section probably isn't recommended for "tourists".

Regards

Greg
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------000507000806090106010203-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 13:09:55 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Wondering about the new boiler plate? Date: Mon, 17 Nov 2008 13:06:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Were you wondering how to get the new boiler plate text right in your draft submissions? You may find it easiest to crib from an existing draft by stealing the top and tail. I think you will find it right in http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-04.txt Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 03:15:03 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , Subject: Re: Slides arriving and being posted Date: Mon, 17 Nov 2008 03:13:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit You are right, I missed this off the list. It will be there before Monday afternoon. A ----- Original Message ----- From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" ; Sent: Sunday, November 16, 2008 10:48 PM Subject: RE: Slides arriving and being posted adrian - looking at your slides and except if i missed it the doc the new release includes clarification on index field encoding. so except if there is any remaining issue from known implementations this doc is also ready for WG LC. thx, -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, November 16, 2008 2:43 PM > To: ccamp@ops.ietf.org > Subject: Slides arriving and being posted > > Hi, > > Thanks to all that have sent slides already. > > Please check that they are correctly posted by visiting > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > We're still missing a few. > > Thanks, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 03:11:21 +0000 Message-ID: <7463A5AFD3FF4622A0296F8EFC5A3855@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Last Call: draft-dasgupta-ccamp-path-comp-analysis (Performance Analysis of Inter-Domain Path Computation Methodologies) to Informational RFC Date: Mon, 17 Nov 2008 03:09:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Heads up! ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Sent: Sunday, November 16, 2008 10:54 PM Subject: Last Call: draft-dasgupta-ccamp-path-comp-analysis (Performance Analysis of Inter-Domain Path Computation Methodologies) to Informational RFC > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Performance Analysis of Inter-Domain Path Computation Methodologies ' > as an Informational 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-12-14. 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-dasgupta-ccamp-path-comp-analysis-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16050&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2008 00:34:32 +0000 From: Nic Neate To: labn - Lou Berger , ALU - Dimitri Papadimitriou CC: "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal , "ccamp@ops.ietf.org" Date: Mon, 17 Nov 2008 00:32:57 +0000 Subject: RE: Agenda updated Thread-Topic: Agenda updated Thread-Index: AclIPeh+pqzmg/rBStmo5d+6gtIapAADXPIg Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A4018DF@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Lou, Dimitri, I agree that association type 2, "Resource Sharing", allows LSPs in differe= nt session to be associated. However, RFC 4873 defines its use as being for make-before-break of segment= recovery LSPs, not for associating the recovery LSP with the protected LSP= . See section 3.2.2: 3.2.2. Resource Sharing Association Type Processing The ASSOCIATION object with an Association Type with the value Resource Sharing is used to enable resource sharing during make- before-break. Resource sharing during make-before-break is defined in [RFC3209]. The defined support only works with LSPs that share the same LSP egress. With the introduction of segment recovery LSPs, it is now possible for an LSP endpoint to change during make-before- break. Association type 1, from RFC 4873, is still used to associate the segment r= ecovery LSP with the protected LSP. Hence the problem described in our dra= ft. Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of labn - Lou Berger Sent: 16 November 2008 22:46 To: Nic Neate Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Perso= nal; ccamp@ops.ietf.org; ALU - Dimitri Papadimitriou Subject: RE: Agenda updated I agree with Dimitri. also, note: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Lou At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: >nick, > >you mention: > >"3.1 Association between LSPs in different sessions > > Segment recovery protecting LSPs may have a different endpoint > address from the corresponding protected LSP. The protected and > protecting LSPs are therefore in different Sessions. The Association > object of type 1 (recovery) is not effective in this case, as the > Association ID can only associate to an LSP ID within the same > Session." > >but segment recovery makes use of: > >"9.1. New Association Type Assignment > > > IANA has made the following assignment to the "Association Types" > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > "RSVP PARAMETERS" registry located at > http://www.iana.org/assignments/rsvp-parameters. > > Value Type > ----- ---- > 2 Resource Sharing (R) [RFC4873]" > >and states: > >"Consider the following topology: > > A---B---C---D---E---F > \ / > G---I > > In this topology, end-to-end protection and recovery is not possible > for an LSP going between node A and node F, but it is possible to > protect/recover a portion of the LSP. Specifically, if the LSP uses > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > can be established along the path [C,G,I,E]." > >[...] > >"Segment protection or restoration is signaled using a working LSP and > one or more segment recovery LSPs. Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path, > e.g., node E shown above. There is no specific requirement on LSP ID > value, Tunnel ID, and Extended Tunnel ID." > >so where is the issue ? > >-d. > > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, November 14, 2008 4:46 PM > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > Dimitri; Aria - Adrian Farrel Personal > > Cc: ccamp@ops.ietf.org > > Subject: FW: Agenda updated > > > > RFC 4873 authors, > > > > Just wanted to flag that I'm presenting a problem in segment > > recovery signaling on Monday, together with a suggested solution. > > > > Problem statement: > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > Suggested fix: > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > Nic > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian Farrel > > Personal > > Sent: 07 November 2008 19:29 > > To: ccamp@ops.ietf.org > > Subject: Agenda updated > > > > I have made some updates. > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > Please shout if there further issues. > > > > Thanks, > > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Nov 2008 23:10:14 +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: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Mon, 17 Nov 2008 00:09:21 +0100 Message-ID: <00275A5B436CA441900CB10936742A38015CD739@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Thread-Index: AclGTUfGUC6gzat4SNynBlKXbv1N/QB8IvMA From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , hi adrian reading this doc. the section 2 2 Background ................................................ 5 2.1 Ethernet Switching ........................................ 5 2.2 Operations, Administration, and Maintenance (OAM) ......... 7 2.3 Terminology ............................................... 8 2.3.1 Concepts .................................................. 8 2.3.2 Abbreviations and Acronyms ................................ 9 2.4 Ethernet and MPLS similarities and differences ............ 10 as it names indicates provides Ethernet background info while i thought the doc. was meant to deal with protocol architecture issues. of course there is a relationship but these sections should better be included in an appendix or so. The sentence "Ethernet is similar to MPLS in that there is a default payload type." i missed the def. of a payload type in RFC3031. Section 2.3 should also be made separate from this background information on Ethernet techno itself.=20 Section 6 reads as a recommendation on protocol usage not on architecture e.g. "It is RECOMMENDED that LMP not be used for Fault management and instead the native Ethernet methods be used." I am not sure to see why an IETF document shall preclude usage of its own protocols except if there is a good reason for (use of LMP on shared medium is tedious since on CC shall be setup between each node). Other comments: " Extensions to support non-IP based LSP identification in signaling, i.e., replacement of the IP address in the RSVP SESSION or SENDER_TSPEC objects, are not permitted under this framework." -> Well i would phrase this in the other way around "Support of Ethernet MUST strictly comply to the GMPLS protocol suite addressing as specific in RFC3471, RFC3473 and related." "This document allows for the support the signaling of Ethernet parameters across multiple domains" -> How do you define the term domain in the present context ? is it related to the Ethernet partitioning and/or segmentation in client/provider MAC address space ? thanks, -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, November 14, 2008 12:34 PM > To: ccamp@ops.ietf.org > Subject: Re: Two week last call on=20 > draft-ietf-ccamp-gmpls-ethernet-arch-03.txt >=20 > Hi, >=20 > Some thoughts in addition to Attila's comments... >=20 > =3D=3D=3D > Abstract > Can you please expand acronyms (as will be required by the RFC Ed.) > I see... > SONET > SDH > TDM > ATM > GMPLS > =3D=3D=3D > Main body of the document. > Each acronym needs to be set out in full the first time it is used. > I see... > SONET > SDH > TDM > ATM > IEEE > ITU > MEF (transfer from later use) > GMPLS > VLAN (transfer from later use) > =3D=3D=3D > Please be consistent with the use of a space in either "IEEE 802" or=20 > "IEEE802" > The space looks better to me. > =3D=3D=3D > Section 1 > OLD > procedures that will need to be changed is dependent > NEW > procedures that will need to be changed are dependent > =3D=3D=3D > Please be consistent "bidirectional" or "bi-directional" > I prefer "bidirectional" and you only use "unidirectional" > =3D=3D=3D > Section 2.3.1 > OLD > o Asymmetric Bandwidth >=20 > This term refers to the property of a Bi-directional=20 > LSP may have > differing bandwidth allocation in each direction. > NEW > o Asymmetric Bandwidth >=20 > This term refers to a property of a bidirectional LSP=20 > that may have > differing bandwidth allocation in each direction. > =3D=3D=3D > Section 2.3.1 > OLD > o Bi-directional Congruent LSP >=20 > This term refers to the property that an LSP shared the same > nodes, ports and links. Ethernet data planes are normally bi- > directional congruent. > NEW > o Bidirectional Congruent LSP >=20 > This term refers to the property of a bidirectional=20 > LSP that uses > only the same nodes, ports, and links in both=20 > directions. Ethernet > data planes are normally bidirectional congruent. > =3D=3D=3D > Section 2.3.1 >=20 > o Shared forwarding >=20 > Shared forwarding is a property of a data path where a single > forwarding entry (VID + DMAC) may be used for frames from > multiple sources (SMAC). Shared forwarding does not change any > data plane behavior it saves forwarding information base (FIB) > entries only. From all other aspects it behaves as if=20 > there were > multiple FIB entries. >=20 > I don't understand the last sentence. Since there is only one=20 > FIB entry, the=20 > behavior cannot be as if there were multiple FIB entries. I=20 > suggest you=20 > either strike this sentence or add an example of what you mean. > =3D=3D=3D > Section 2.3.1 > o Hierarchical Eth-LSP >=20 > Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and > tunneled, either individually or bundled, with other=20 > LSPs through > a domain. >=20 > I don't like this definition of hierarchical! Normally, we=20 > refer to the=20 > hierarchical LSP as the LSP that is the tunnel, not the LSP that is=20 > encapsulated. I think it would be helpful to remain=20 > consistent with RFC4206. > =3D=3D=3D > Section 2.4 etc. > Please capitalise section headings > =3D=3D=3D > Section 2.4 > Ethernet is similar to MPLS in that there is a default=20 > payload type. > In MPLS, the default payload is either another MPLS label or an IP > packet. The IP packet may carry any type of service IP carries. > Ethernet assumes an Ethernet frame as the default payload.=20 > The actual > service can be anything that Ethernet carries. >=20 > I find this paragraph pretty weird! > - What do you mean by a "default payload". Try telling the PWE3 > working group that LSPs carry either another MPLS label or an > IP packet! > - How can "the default" payload be either one thing or another? > - In what way does Ethernet assume that the default payload of > Ethernet is also Ethernet? When would that assumption stop? > It sounds arbitrarily recursive! > It might help if you explained what value there is to knowing=20 > the default=20 > payload type. If there is no value *to*=20 > the*work*we*are*doing* in this=20 > document, then why bother mentioning it? > =3D=3D=3D > Section 2.4 > Ethernet bridging is different from MPLS in that while the=20 > switching > decision is taken on whatever is defined as the Ethernet=20 > label, that > label is usually not swapped at each hop. >=20 > "Usually"? > Note that in MPLS you can use the same label on incoming and outgoing=20 > interfaces, but because the label could be swapped, we=20 > implement a swapping=20 > mechanism in all cases. > Now, "usually" implies that sometimes the label may be=20 > swapped. This has=20 > significant implications for implementation. >=20 > Perhaps you need to clarify this paragraph quite a bit. It=20 > might also help=20 > to discuss the context of the label. MPLS label contexts fall=20 > into three=20 > categories: > - node > - link > - upstream neighbor > What can you say about Ethernet? > =3D=3D=3D > Section 3 > You list > - priority level; > - preemption characteristics; > How are these different? > =3D=3D=3D > Section 3 > Remove spare blank line between last 2 paras > =3D=3D=3D > Section 1 and Section 4.1 > Please add a reference where you name LMP > =3D=3D=3D > Section 5 > I think you should reference RFC3473 alongside RFC3471 > =3D=3D=3D > Section 5 > OLD > Signaling enables the ability to > dynamically establish a path from one ingress or egress node. > NEW > Signaling enables the ability to > dynamically establish a path from an ingress node to an > egress node. > =3D=3D=3D > Section 5 > Given this, Eth- > LSPs MUST always use paths that share the same routes and fates. > I believe you have defined a term specially for this? > =3D=3D=3D > Section 5 > Eth- > LSPs may be either P2P or P2MP (see [RFC4875]). > You should probably add that only unidirectional P2MP Eth-LSPs are=20 > supported. > =3D=3D=3D > Section 5 > Note that standard GMPLS does not support different=20 > bandwidth in each > direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric > bandwidth bidirectional LSPs are required. > Suggest you change to > Note that GMPLS as originally defined in [RFC3471] and=20 > [RFC3473] does > not support... > =3D=3D=3D > Section 8 > More detail will be added to the section in a later revision. > You are running out of time :-) > =3D=3D=3D > Section 9 > OLD > the ports over which a UNI is defined is trusted > NEW > the ports over which a UNI are defined is trusted > =3D=3D=3D > Section 9 > This section is a bit sparse. > You should add a reference to=20 > draft-ietf-mpls-mpls-and-gmpls-security-framework (currently rev 04) > You should describe why the change in data plane type does=20 > not impact the=20 > control plane security. > You should mention the difference between in-band and=20 > out-of-band control=20 > planes in the Ethernet network since in this case, the data=20 > plane type does=20 > impact security. In particular, the in-band control plane can=20 > be used to=20 > attack the data plane capacity, and access to the data plane=20 > can be used to=20 > attack the control plane. > =3D=3D=3D >=20 > Thanks, > Adrian >=20 > PS. When you submit the updates, please use the new=20 > boilerplate and use=20 > idnits to verify everything. >=20 > ----- Original Message -----=20 > From: "Adrian Farrel" > To: > Sent: Wednesday, October 29, 2008 7:47 PM > Subject: Two week last call on=20 > draft-ietf-ccamp-gmpls-ethernet-arch-03.txt >=20 >=20 > > This email starts a two week working group last call on=20 > "GMPLS Ethernet=20 > > Label Switching Architecture and Framework" > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth > ernet-arch-03.txt > > > > The I-D is marked as Informational. > > > > Please send your comments to the list by 12 noon GMT Friday=20 > 14th November. > > > > Thanks, > > Adrian and Deborah > > > >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Nov 2008 22:49:24 +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: Slides arriving and being posted Date: Sun, 16 Nov 2008 23:48:55 +0100 Message-ID: <00275A5B436CA441900CB10936742A38015CD738@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Slides arriving and being posted Thread-Index: AclH8aWFOOOek7QhSt2A+L8D6SkHTwAS5hTw From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , =20 adrian - looking at your slides and except if i missed it the doc the new release includes clarification on index field encoding. so except if there is any remaining issue from known implementations this doc is also ready for WG LC.=20 thx, -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, November 16, 2008 2:43 PM > To: ccamp@ops.ietf.org > Subject: Slides arriving and being posted >=20 > Hi, >=20 > Thanks to all that have sent slides already. >=20 > Please check that they are correctly posted by visiting=20 > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm >=20 > We're still missing a few. >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Nov 2008 22:46: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=XOx9LiFUHqi7Oz0/fidAK2+gB+hWspgL37r1XKeBJ+GI4/3pDDGWwUvn3XCCvQd80/0XmxvhAyxIMw2neLj5/b6La8/PIqytY2fSgVnmbNtyEQdI0XeRTRaC1Ab0SQZ8; Date: Sun, 16 Nov 2008 17:45:57 -0500 To: "Nic Neate" From: Lou Berger Subject: RE: Agenda updated Cc: "Lou Berger" ,, ,, "PAPADIMITRIOU Dimitri" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: I agree with Dimitri. also, note: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Lou At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote: >nick, > >you mention: > >"3.1 Association between LSPs in different sessions > > Segment recovery protecting LSPs may have a different endpoint > address from the corresponding protected LSP. The protected and > protecting LSPs are therefore in different Sessions. The Association > object of type 1 (recovery) is not effective in this case, as the > Association ID can only associate to an LSP ID within the same > Session." > >but segment recovery makes use of: > >"9.1. New Association Type Assignment > > > IANA has made the following assignment to the "Association Types" > Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the > "RSVP PARAMETERS" registry located at > http://www.iana.org/assignments/rsvp-parameters. > > Value Type > ----- ---- > 2 Resource Sharing (R) [RFC4873]" > >and states: > >"Consider the following topology: > > A---B---C---D---E---F > \ / > G---I > > In this topology, end-to-end protection and recovery is not possible > for an LSP going between node A and node F, but it is possible to > protect/recover a portion of the LSP. Specifically, if the LSP uses > a working path of [A,B,C,D,E,F], then a protection or restoration LSP > can be established along the path [C,G,I,E]." > >[...] > >"Segment protection or restoration is signaled using a working LSP and > one or more segment recovery LSPs. Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path, > e.g., node E shown above. There is no specific requirement on LSP ID > value, Tunnel ID, and Extended Tunnel ID." > >so where is the issue ? > >-d. > > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, November 14, 2008 4:46 PM > > To: labn - Lou Berger; IBryskin@advaoptical.com; > > PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal > > Cc: ccamp@ops.ietf.org > > Subject: FW: Agenda updated > > > > RFC 4873 authors, > > > > Just wanted to flag that I'm presenting a problem in segment > > recovery signaling on Monday, together with a suggested solution. > > > > Problem statement: > > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > > Suggested fix: > > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. > > > > > > Nic > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian > > Farrel Personal > > Sent: 07 November 2008 19:29 > > To: ccamp@ops.ietf.org > > Subject: Agenda updated > > > > I have made some updates. > > > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm > > > > Please shout if there further issues. > > > > Thanks, > > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Nov 2008 22:38:49 +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: Agenda updated Date: Sun, 16 Nov 2008 23:36:59 +0100 Message-ID: <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Agenda updated Thread-Index: AclBEdrEXjU0mOCKQ3CvjSu7MB8uLADwUelgANoLACA= From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , "labn - Lou Berger" , , "Aria - Adrian Farrel Personal" Cc: nick, you mention: "3.1 Association between LSPs in different sessions Segment recovery protecting LSPs may have a different endpoint address from the corresponding protected LSP. The protected and protecting LSPs are therefore in different Sessions. The Association object of type 1 (recovery) is not effective in this case, as the Association ID can only associate to an LSP ID within the same Session." but segment recovery makes use of: "9.1. New Association Type Assignment IANA has made the following assignment to the "Association Types" Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. Value Type ----- ---- 2 Resource Sharing (R) [RFC4873]"=20 and states: "Consider the following topology: A---B---C---D---E---F \ / G---I In this topology, end-to-end protection and recovery is not possible for an LSP going between node A and node F, but it is possible to protect/recover a portion of the LSP. Specifically, if the LSP uses a working path of [A,B,C,D,E,F], then a protection or restoration LSP can be established along the path [C,G,I,E]."=20 [...] "Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path, e.g., node E shown above. There is no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID." so where is the issue ? -d. > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Friday, November 14, 2008 4:46 PM > To: labn - Lou Berger; IBryskin@advaoptical.com;=20 > PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal > Cc: ccamp@ops.ietf.org > Subject: FW: Agenda updated >=20 > RFC 4873 authors, >=20 > Just wanted to flag that I'm presenting a problem in segment=20 > recovery signaling on Monday, together with a suggested solution. >=20 > Problem statement:=20 > http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00. > Suggested fix:=20 > http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00. >=20 >=20 > Nic >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian=20 > Farrel Personal > Sent: 07 November 2008 19:29 > To: ccamp@ops.ietf.org > Subject: Agenda updated >=20 > I have made some updates. >=20 > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm >=20 > Please shout if there further issues. >=20 > Thanks, > Adrian >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Nov 2008 13:45:45 +0000 Message-ID: <10D6170A47D844D4B23F91AFB9C72D36@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Slides arriving and being posted Date: Sun, 16 Nov 2008 13:42:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Thanks to all that have sent slides already. Please check that they are correctly posted by visiting http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm We're still missing a few. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2008 21:01:13 +0000 Message-ID: <0CC568AD2A524BECA648AE622D9A8CB8@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last callcomplete : draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Fri, 14 Nov 2008 20:59:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Authors, You received some comments. Mainly editorial. The sooner you post a revision, the sooner it will go forward. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, October 29, 2008 7:47 PM Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt > 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: Fri, 14 Nov 2008 15:48:18 +0000 From: Nic Neate To: labn - Lou Berger , "IBryskin@advaoptical.com" , ALU - Dimitri Papadimitriou , Aria - Adrian Farrel Personal CC: "ccamp@ops.ietf.org" Date: Fri, 14 Nov 2008 15:46:25 +0000 Subject: FW: Agenda updated Thread-Topic: Agenda updated Thread-Index: AclBEdrEXjU0mOCKQ3CvjSu7MB8uLADwUelg Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 RFC 4873 authors, Just wanted to flag that I'm presenting a problem in segment recovery signa= ling on Monday, together with a suggested solution. Problem statement: http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-si= gnaling-00. Suggested fix: http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-= fix-00. Nic -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of Aria - Adrian Farrel Personal Sent: 07 November 2008 19:29 To: ccamp@ops.ietf.org Subject: Agenda updated I have made some updates. http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm Please shout if there further issues. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2008 12:01:39 +0000 Message-ID: <0FE2923B03104207BBFBC2098F27399D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "tom.petch" , Subject: Re: A BNF specification for RSVP-GMPLS and LMP Date: Fri, 14 Nov 2008 12:00:50 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Tom, > I have seen this announcement on a number of lists but I am unclear where > you > want the discussion to take place. Anywhere :-) If you have issues specific to the use of the I-D in a particular set of documents for a protocol, take it to the list that owns that protocol. If you have issues related to the draft itself, take it to the routing discussion list (routing-discussion@ietf.org) Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2008 11:48:40 +0000 Message-ID: <002601c94645$3f25cf20$0601a8c0@allison> Reply-To: "tom.petch" From: "tom.petch" To: "Adrian Farrel" , Subject: Re: A BNF specification for RSVP-GMPLS and LMP Date: Wed, 12 Nov 2008 18:42:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian I have seen this announcement on a number of lists but I am unclear where you want the discussion to take place. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: Sent: Friday, October 24, 2008 5:05 PM Subject: A BNF specification for RSVP-GMPLS and LMP > 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: Fri, 14 Nov 2008 11:36:32 +0000 Message-ID: <6F406347BCC84ACBADFEFB8D805A04C6@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Fri, 14 Nov 2008 11:34:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi, Some thoughts in addition to Attila's comments... === Abstract Can you please expand acronyms (as will be required by the RFC Ed.) I see... SONET SDH TDM ATM GMPLS === Main body of the document. Each acronym needs to be set out in full the first time it is used. I see... SONET SDH TDM ATM IEEE ITU MEF (transfer from later use) GMPLS VLAN (transfer from later use) === Please be consistent with the use of a space in either "IEEE 802" or "IEEE802" The space looks better to me. === Section 1 OLD procedures that will need to be changed is dependent NEW procedures that will need to be changed are dependent === Please be consistent "bidirectional" or "bi-directional" I prefer "bidirectional" and you only use "unidirectional" === Section 2.3.1 OLD o Asymmetric Bandwidth This term refers to the property of a Bi-directional LSP may have differing bandwidth allocation in each direction. NEW o Asymmetric Bandwidth This term refers to a property of a bidirectional LSP that may have differing bandwidth allocation in each direction. === Section 2.3.1 OLD o Bi-directional Congruent LSP This term refers to the property that an LSP shared the same nodes, ports and links. Ethernet data planes are normally bi- directional congruent. NEW o Bidirectional Congruent LSP This term refers to the property of a bidirectional LSP that uses only the same nodes, ports, and links in both directions. Ethernet data planes are normally bidirectional congruent. === Section 2.3.1 o Shared forwarding Shared forwarding is a property of a data path where a single forwarding entry (VID + DMAC) may be used for frames from multiple sources (SMAC). Shared forwarding does not change any data plane behavior it saves forwarding information base (FIB) entries only. From all other aspects it behaves as if there were multiple FIB entries. I don't understand the last sentence. Since there is only one FIB entry, the behavior cannot be as if there were multiple FIB entries. I suggest you either strike this sentence or add an example of what you mean. === Section 2.3.1 o Hierarchical Eth-LSP Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and tunneled, either individually or bundled, with other LSPs through a domain. I don't like this definition of hierarchical! Normally, we refer to the hierarchical LSP as the LSP that is the tunnel, not the LSP that is encapsulated. I think it would be helpful to remain consistent with RFC4206. === Section 2.4 etc. Please capitalise section headings === Section 2.4 Ethernet is similar to MPLS in that there is a default payload type. In MPLS, the default payload is either another MPLS label or an IP packet. The IP packet may carry any type of service IP carries. Ethernet assumes an Ethernet frame as the default payload. The actual service can be anything that Ethernet carries. I find this paragraph pretty weird! - What do you mean by a "default payload". Try telling the PWE3 working group that LSPs carry either another MPLS label or an IP packet! - How can "the default" payload be either one thing or another? - In what way does Ethernet assume that the default payload of Ethernet is also Ethernet? When would that assumption stop? It sounds arbitrarily recursive! It might help if you explained what value there is to knowing the default payload type. If there is no value *to* the*work*we*are*doing* in this document, then why bother mentioning it? === Section 2.4 Ethernet bridging is different from MPLS in that while the switching decision is taken on whatever is defined as the Ethernet label, that label is usually not swapped at each hop. "Usually"? Note that in MPLS you can use the same label on incoming and outgoing interfaces, but because the label could be swapped, we implement a swapping mechanism in all cases. Now, "usually" implies that sometimes the label may be swapped. This has significant implications for implementation. Perhaps you need to clarify this paragraph quite a bit. It might also help to discuss the context of the label. MPLS label contexts fall into three categories: - node - link - upstream neighbor What can you say about Ethernet? === Section 3 You list - priority level; - preemption characteristics; How are these different? === Section 3 Remove spare blank line between last 2 paras === Section 1 and Section 4.1 Please add a reference where you name LMP === Section 5 I think you should reference RFC3473 alongside RFC3471 === Section 5 OLD Signaling enables the ability to dynamically establish a path from one ingress or egress node. NEW Signaling enables the ability to dynamically establish a path from an ingress node to an egress node. === Section 5 Given this, Eth- LSPs MUST always use paths that share the same routes and fates. I believe you have defined a term specially for this? === Section 5 Eth- LSPs may be either P2P or P2MP (see [RFC4875]). You should probably add that only unidirectional P2MP Eth-LSPs are supported. === Section 5 Note that standard GMPLS does not support different bandwidth in each direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric bandwidth bidirectional LSPs are required. Suggest you change to Note that GMPLS as originally defined in [RFC3471] and [RFC3473] does not support... === Section 8 More detail will be added to the section in a later revision. You are running out of time :-) === Section 9 OLD the ports over which a UNI is defined is trusted NEW the ports over which a UNI are defined is trusted === Section 9 This section is a bit sparse. You should add a reference to draft-ietf-mpls-mpls-and-gmpls-security-framework (currently rev 04) You should describe why the change in data plane type does not impact the control plane security. You should mention the difference between in-band and out-of-band control planes in the Ethernet network since in this case, the data plane type does impact security. In particular, the in-band control plane can be used to attack the data plane capacity, and access to the data plane can be used to attack the control plane. === Thanks, Adrian PS. When you submit the updates, please use the new boilerplate and use idnits to verify everything. ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, October 29, 2008 7:47 PM Subject: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt > 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, 12 Nov 2008 15:01:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls workinggroupdocuments Date: Wed, 12 Nov 2008 15:58:28 +0100 Message-ID: <43284B5A95E36B4AB4A91EBA4E0FC31EF251AE@DEMUEXC030.nsn-intra.net> Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls workinggroupdocuments Thread-Index: Ack9vNPuOTzVZoPIS8u3G2GbWI2bwAG/pBpwAAawcoA= From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Annamaria Fulignoli" , "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , I have also issued a few weeks ago some comments and questions on the = framework. I hope the editors will address these comments.=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of ext Annamaria Fulignoli Sent: Wednesday, November 12, 2008 13:45 To: Loa Andersson; mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; = mpls-tp@ietf.org Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls = workinggroupdocuments Hi all, I support for all the four. However I wonder if it's possible to have some more clarification now = about draft-blb-mpls-tp-framework-01, Figure 3 and associated Editor's = note: "The figure above arose from discussions in the MPLS-TP design team. It = will be clarified in a future version of this draft" It's not clear to me the issue regarding OAM dmux without GAL/GACH.=20 My understanding was that:=20 "OAM, protection and forwarding of data packets MUST be able to operate = without IP forwarding support " as reported by the same draft section 2 and "... the operation of OAM functions MUST NOT rely on IP routing and = forwarding capabilities" as reported by draft-vigoureux-mpls-tp-oam-requirements-01 (section 2.1) Thank you and Best Regards Annamaria -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Loa Andersson Sent: luned=EC 3 novembre 2008 15.00 To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: [mpls] Poll for MPLS-TP documents to become mpls working = groupdocuments Working group(s) we have four documents from the MPLS-TP effort that the authors think = are ready to become working group documents. The documents are listed = below. This mail initiate a two week working poll for comments on three of the = documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for = draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a = bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- 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 = _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2008 00:11:36 +0000 Message-ID: <56BC37215ECA446B84C9DB2EDEC1969D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: NOTE WELL: New Boilerplate Text Required for all new Submissions to IETF Date: Wed, 12 Nov 2008 00:08:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Note well. Your I-Ds will not be posted unless they conform to new boiler-plate requirements. Adrian ----- Original Message ----- From: "Ed Juskevicius" To: "IETF Discussion" ; ; ; ; ; "RFC Editor" ; Cc: Sent: Tuesday, November 11, 2008 11:03 PM Subject: Announcement: New Boilerplate Text Required for all new Submissionsto IETF > Greetings. This message is to draw your attention to the significance > of the publication of RFC5377 and RFC5378 earlier today. > > * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be > Granted in IETF Documents > * RFC5378 is Rights Contributors Provide to the IETF Trust > > Note that RFC5378 is also BCP0078. RFC5378 is an update to RFC2026, and > RFC5378 obsoletes both RFC3978 and RFC4748. > > Coincident with the above, the IETF Trustees have posted a new policy > document with guidance to the community on: > * Legal Provisions Relating to IETF Documents at > http://trustee.ietf.org/license-info/ > > Taken as a set, the documents listed above specify changes that are now > required in all new submissions into the IETF. > > Henrik Levkowetz has updated the idnit tool and AMS have updated the > Internet-Draft submission tool to reflect the new requirements. An > update to the xml2rfc has been requested. > > Please review the "Legal Provisions Relating to IETF Documents" and > RFC5378 to discover the new boilerplate text that is now required. > Please also take action to update the tools you use for creating your > documents. > > New submissions using either the old or the new boilerplate text will be > accepted starting today, until 01h00 UTC on December 16th, 2008. After > this cutoff date, all new submissions will be required to use ONLY the > new boilerplate text. All submissions using old boilerplate text after > the cutoff date will be rejected. > > Regards and FYI. > > Ed Juskevicius > IETF Trust Chair > edj@nortel.com > > p.s. - Don't be surprised if you see periodic reminders about this as we > approach December 16th. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Nov 2008 08:44:59 +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: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt Date: Tue, 11 Nov 2008 09:41:39 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E91057D04A8@esealmw116.eemea.ericsson.se> Thread-Topic: Two week last call on draft-ietf-ccamp-gmpls-ethernet-arch-03.txt thread-index: Ack6AA/bxf8lkrpkSMuljVMOwLadUQJ2R12g From: "Attila Takacs" To: "Don Fedyk" , , "Loa Andersson" Cc: "Adrian Farrel" , Hi all, Some comments on the draft, mostly editorial. Best regards, Attila -Move the abbreviation section (2.3.2) in the beginning of the document. I would consider moving the whole terminology section (2.3) forward. -Page 3, delete "Document History" -Page 3, Introduction, last sentence of second paragraph, change "but not an explicitly" ->"but not on explicitly" -Page 3, Introduction, 5th paragraph: add a new reference to 802.1ad and reword the first sentence -Page 4, last paragraph change: "This document introduces and explains the concept of an Ethernet Label Switched Path (Eth-LSP)." -> "This document introduces and explains GMPLS control plane deployment for Ethernet and the concept of the Ethernet Label Switched Path (Eth-LSP)." -Page 5, Background, second paragraph, first sentence change: "this section is based on the on-going work" -> "this section is based on both finished and on-going work" -Page 7, bullet on I-tagged interfaces, change second sentence: "An I-Tag contains a service identifier (24 bit I-SID) and priority markings as well as some other flags." -> "An I-Tag contains a service identifier (24 bit I-SID) and priority markings as well as some other fields." -Page 7, first paragraph after the bullet list, change: "In general, the different switching type determines" -> "In general, the switching type determines" and "The type may also" -> "The switching type may also" -Page 7, last paragraph, delete: "For the Eth-LSP unicast mode of behavior, the hardware performs unicast packet forwarding of known MAC addresses leveraging existing Ethernet forwarding." -Page 8, OAM, last paragraph, reword to: "Both Y.1731 & 802.1ag assumes that bidirectional transactions (e.g., LBM/LBR) use the same VID in both directions. However in some scenarios, especially with explicitly routed paths [802.1Qay], it is possible that different VIDs are used upstream and downstream. In the context of [802.1Qay] work is ongoing to update [802.1ag] to support such scenarios."=20 -Page 8, Bi-directional Congruent LSP, typo, "LSP shared" -> "LSP shares" -Page 8, Shared forwarding: add at the end: "In contrast to merging where control plane states as well as forwarding entries are merged, with shared forwarding dedicated states for all Eth-LSP are maintained regardless of shared forwarding entries." -Page 8, add the definition of Eth-LSPs: "Eth-LSP: This term refers to Ethernet service paths that are controlled via GMPLS." -Page 10, Framework, first sentence: remove parenthesis around GMPLS -Page 12, first paragraph reorder to read: "...This valid MAC checking and broadcast supports Ethernet learning. A special case is when a VID is defined for only two ports on one bridge, effectively resulting in a p2p forwarwading constraint, in this case all frames tagged with that VID received over one of these ports are forward over the other port without address learning. [802.1Qay] allows for turning off learning and hence the broadcast mechanism providing means to create explicitly routed Ethernet connections." -Page 16, section 8, delete last sentence "More detail will be added to the section in a later revision." and/or add further details :-) =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, October 29, 2008 8:48 PM > To: ccamp@ops.ietf.org > Subject: Two week last call on=20 > draft-ietf-ccamp-gmpls-ethernet-arch-03.txt >=20 > This email starts a two week working group last call on=20 > "GMPLS Ethernet Label Switching Architecture and Framework" >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth > ernet-arch-03.txt >=20 > The I-D is marked as Informational. >=20 > Please send your comments to the list by 12 noon GMT Friday=20 > 14th November. >=20 > Thanks, > Adrian and Deborah=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Nov 2008 19:34:31 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Protocol Action: 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE' to Proposed Standard Message-Id: <20081110193217.BC1BB3A6A9F@core3.amsl.com> Date: Mon, 10 Nov 2008 11:32:17 -0800 (PST) The IESG has approved the following document: - 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE ' 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-rfc4420bis-03.txt Technical Summary This document replaces and obsoletes RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. This allows consistency with the use of TLV data structures in other related documents, and therefore essentially corrects a bug in 4420. Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. Working Group Summary This document corrects a bug in RFC4220 which was found during interoperability testing. Once this bug was found, there was no controversy regarding how to fix this. Document Quality Current implementations are compatible with this document (and therefore no longer compatible with one detail in RFC4220). Personnel Deborah Brungard is the document shepherd. Ross Callon is the responsible AD. RFC Editor Note Please update section 3 as follows: OLD Length Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four- octet aligned. Value The data for the TLV padded as described above. NEW Length Indicates the total length of the TLV in octets. That is the combined length of the Type, Length, and Value fields, i.e., four plus the length of the Value field in octets. The entire TLV MUST be padded with between zero and three trailing zeros to make it four-octet aligned. The Length field does not count any padding. Value The data carried in the TLV. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Nov 2008 13:18:20 +0000 Message-ID: <8FCD06A61E6C40518AF2E84A0E30F1C0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Slides Date: Sun, 9 Nov 2008 13:16:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Please start sending in your slides so that I can post them for everyone to see. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Nov 2008 19:30:57 +0000 Message-ID: <984EFCBC86A84BD59181C6E179499780@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Agenda updated Date: Fri, 7 Nov 2008 19:28:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit I have made some updates. http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm Please shout if there further issues. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Nov 2008 21:28: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: RE: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Thu, 6 Nov 2008 16:26:54 -0500 Message-ID: Thread-Topic: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbAAAD+ZwABm7fF0A== From: "Zafar Ali (zali)" To: "AISSAOUI Mustapha" , "Lou Berger" Cc: , "Newton, Jonathan" , , , "Anca Zamfir (ancaz)" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2949; t=1226006814; x=1226870814; 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:=20RE=3A=20[mpls]=20Updates=20to=20draft-ietf-ccam p-mpls-graceful-shutdown |Sender:=20 |To:=20=22AISSAOUI=20Mustapha=22=20,=0A=20=20=20=20=20=20=20=20=22Lou=20Berger=22 =20; bh=M/y1Y3DEF7WpFFRoHyiGwMhBHZGmdpTLsajBG5IfaSs=; b=F42WUN+I/O5hU7OyLFzyeZatIHzrODeZKNdJPMw/xTYcB0BofsakrQ+lpx fPwwOqSTHwAEzi6ozS3VDp1oNTofeRohkpXo1NJCIoNl0JIxkDY/2s+sXcpb /saV+nwRhM; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Mustapha-=20 I think once we address Lou's comment, that will also address your comment. So please wait for the new revision. We can try to publish it during the IETF week.=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel-lucent.com]=20 > Sent: Thursday, November 06, 2008 1:05 PM > To: Zafar Ali (zali); Lou Berger > Cc: mpls@ietf.org; Newton, Jonathan; jpv@cisco.com;=20 > ccamp@ops.ietf.org; Anca Zamfir (ancaz) > Subject: RE: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown >=20 > Hi Ali, > I have an issue with not providing backwards compatibility=20 > with the "Notify" error code and the error sub-codes for link=20 > and node maintenance defined in RFC 4736. This draft has been=20 > using these codes for almost four years now and it is not=20 > acceptable they get changed in last call. >=20 > Furthermore, draft-ietf-mpls-gmpls-lsp-reroute-02.txt=20 > suggests backwards compatibility must be provided when=20 > required. I believe this is one of those cases. When=20 > draft-ietf-mpls-gmpls-lsp-reroute-02.txt passes WG last call,=20 > it makes perfect sense to require new applications to start using it. >=20 > Regards, > Mustapha.=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > > Of Zafar Ali (zali) > > Sent: Wednesday, October 29, 2008 12:35 PM > > To: Lou Berger > > Cc: mpls@ietf.org; Newton, Jonathan; jpv@cisco.com;=20 > > ccamp@ops.ietf.org; Anca Zamfir (ancaz) > > Subject: Re: [mpls] Updates to=20 > draft-ietf-ccamp-mpls-graceful-shutdown > >=20 > > Hi Lou- > >=20 > > > -----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;=20 > > > 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)? =20 > > Is it that > > > the reroute document isn't sufficient clear on how to > > indicated each > > > of the 4? Is it some other reason? > > >=20 > >=20 > > This is because headend may be able to compute alternate route=20 > > ("reroute" action) for mb4b differently, depending on the resource=20 > > under graceful shutdown, as detailed in the document. Hence=20 > one code=20 > > is define for TE node, TE link, component link of a bundled=20 > TE link,=20 > > and label resource, each. > >=20 > > Thanks > >=20 > > Regards... Zafar > >=20 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Nov 2008 18:09:16 +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] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Date: Thu, 6 Nov 2008 12:04:48 -0600 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04D070A8@USDALSMBS03.ad3.ad.alcatel.com> Thread-Topic: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown Thread-Index: Ack53yEy/I+XfyB5TO2rHdRpEseqEwAA9bbAAAD+ZwA= From: "AISSAOUI Mustapha" To: "Zafar Ali \(zali\)" , "Lou Berger" Cc: , "Newton, Jonathan" , , , "Anca Zamfir \(ancaz\)" Hi Ali, I have an issue with not providing backwards compatibility with the "Notify" error code and the error sub-codes for link and node maintenance defined in RFC 4736. This draft has been using these codes for almost four years now and it is not acceptable they get changed in last call. Furthermore, draft-ietf-mpls-gmpls-lsp-reroute-02.txt suggests backwards compatibility must be provided when required. I believe this is one of those cases. When draft-ietf-mpls-gmpls-lsp-reroute-02.txt passes WG last call, it makes perfect sense to require new applications to start using it. Regards, Mustapha.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Zafar Ali (zali) > Sent: Wednesday, October 29, 2008 12:35 PM > To: Lou Berger > Cc: mpls@ietf.org; Newton, Jonathan; jpv@cisco.com;=20 > ccamp@ops.ietf.org; Anca Zamfir (ancaz) > Subject: Re: [mpls] Updates to draft-ietf-ccamp-mpls-graceful-shutdown >=20 > Hi Lou- =20 >=20 > > -----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;=20 > > 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)? =20 > Is it that=20 > > the reroute document isn't sufficient clear on how to=20 > indicated each=20 > > of the 4? Is it some other reason? > >=20 >=20 > This is because headend may be able to compute alternate=20 > route ("reroute" action) for mb4b differently, depending on=20 > the resource under graceful shutdown, as detailed in the=20 > document. Hence one code is define for TE node, TE link,=20 > component link of a bundled TE link, and label resource, each.=20 >=20 > Thanks >=20 > Regards... Zafar=20 >=20 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Nov 2008 11:09:10 +0000 Message-ID: <49102CDC.6090404@hitachi.com> Date: Tue, 04 Nov 2008 20:07:08 +0900 From: Masahiko Mizutani User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" , pwe3 , L2VPN , ccamp , "ahtmpls@itu.int" , "mpls-tp@ietf.org" Subject: Re: [mpls-tp] Poll for MPLS-TP documents to become mpls working group documents Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support all documents. Regards, Masahiko Mizutani Loa Andersson wrote: > Working group(s) > > we have four documents from the MPLS-TP effort that the authors think > are ready to become working group documents. The documents are listed below. > > This mail initiate a two week working poll for comments on three of the > documents, for the fourth document > (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. > > Please send your comments before Nov 11 for > draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- > > *Note:* > Please send your responses to the *mpls working group mailing list*, > a bit of discipline is needed, "replay all" won't do the trick ;). > > Comments Nov 11 the latest: > > Title : MPLS Generic Associated Channel > Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, > R. Aggarwal > Filename : draft-bocci-mpls-tp-gach-gal-00.txt > Pages : 16 > Date : 2008-10-27 > > > Comments Nov 17 the latest: > > Title : MPLS-TP Requirements > Author(s): B. Niven-Jenkins, et al. > Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt > Pages : 18 > Date : 2008-10-31 > > Title : A Framework for MPLS in Transport Networks > Author(s): M. Bocci, S. Bryant > Filename : draft-blb-mpls-tp-framework-01.txt > Pages : 27 > Date : 2008-10-31 > > Title : Requirements for OAM in MPLS Transport Networks > Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi > Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt > Pages : 16 > Date : 2008-11-1 > > Loa and George > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Nov 2008 19:45: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: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 14:44:58 -0500 Message-ID: <6535C9CED6F87446B41D20EF170F23621385AC@mamxm01.ciena.com> Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vNVtCHsPlZ7CSQKUEf/VFXm4wAAL8wFQ From: "Shah, Himanshu" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , support all. /himanshu=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, November 03, 2008 9:00 AM To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Working group(s) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Nov 2008 19:01: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-gmpls-mln-extensions-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103190001.D5F203A6BF6@core3.amsl.com> Date: Mon, 3 Nov 2008 11:00:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) Author(s) : D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Roux, E. Oki, I. Inoue, E. Dotaro, G. Grammel Filename : draft-ietf-ccamp-gmpls-mln-extensions-03.txt Pages : 21 Date : 2008-11-3 There are requirements for the support of networks comprising LSRs with different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer/Multi- Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-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-mln-extensions-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3105108.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Nov 2008 18:15:45 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rwa-info-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103181501.515243A686D@core3.amsl.com> Date: Mon, 3 Nov 2008 10:15:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-info-01.txt Pages : 17 Date : 2008-11-03 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs, particularly in cases where there are no or a limited number of wavelength converters available. This model currently does not include optical impairments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-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-rwa-info-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03100105.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Nov 2008 17:50:32 +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-tp] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 18:48:37 +0100 Message-ID: <43284B5A95E36B4AB4A91EBA4E0FC31EECCB64@DEMUEXC030.nsn-intra.net> Thread-Topic: [mpls-tp] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vOlzwcsBl3UNRy2LKuiue/RPHgAH3Sgg From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , Support for all. -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Monday, November 03, 2008 16:00 To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: [mpls-tp] Poll for MPLS-TP documents to become mpls working groupdocuments Working group(s) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George --=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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Nov 2008 16:45:42 +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: Poll for MPLS-TP documents to become mpls working group documents Date: Mon, 3 Nov 2008 22:13:05 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965021D78F8@INEXC1U01.in.lucent.com> Thread-Topic: Poll for MPLS-TP documents to become mpls working group documents thread-index: Ack9vI5OU+9/OWbJRrGHPlXvQ+wV6AAFp9ag From: "Dutta, Pranjal K \(Pranjal\)" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , Support for all. Thanks, Pranjal=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, November 03, 2008 6:00 AM To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int; mpls-tp@ietf.org Subject: Poll for MPLS-TP documents to become mpls working group documents Working group(s) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- 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: Mon, 03 Nov 2008 16:01: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: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 09:59:55 -0600 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04C95BFE@USDALSMBS03.ad3.ad.alcatel.com> Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vM/bULPCz8SJTFOBGgynqGwEfAAEGBrA From: "AISSAOUI Mustapha" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , support all. Mustapha.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Monday, November 03, 2008 9:00 AM > To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int;=20 > mpls-tp@ietf.org > Subject: [mpls] Poll for MPLS-TP documents to become mpls=20 > working groupdocuments >=20 > Working group(s) >=20 > we have four documents from the MPLS-TP effort that the=20 > authors think are ready to become working group documents.=20 > The documents are listed below. >=20 > This mail initiate a two week working poll for comments on=20 > three of the documents, for the fourth document > (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. >=20 > Please send your comments before Nov 11 for=20 > draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- >=20 > *Note:* > Please send your responses to the *mpls working group mailing=20 > list*, a bit of discipline is needed, "replay all" won't do=20 > the trick ;). >=20 > Comments Nov 11 the latest: >=20 > Title : MPLS Generic Associated Channel > Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, > R. Aggarwal > Filename : draft-bocci-mpls-tp-gach-gal-00.txt > Pages : 16 > Date : 2008-10-27 >=20 >=20 > Comments Nov 17 the latest: >=20 > Title : MPLS-TP Requirements > Author(s): B. Niven-Jenkins, et al. > Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt > Pages : 18 > Date : 2008-10-31 >=20 > Title : A Framework for MPLS in Transport Networks > Author(s): M. Bocci, S. Bryant > Filename : draft-blb-mpls-tp-framework-01.txt > Pages : 27 > Date : 2008-10-31 >=20 > Title : Requirements for OAM in MPLS Transport Networks > Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi > Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt > Pages : 16 > Date : 2008-11-1 >=20 > Loa and George >=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: Mon, 03 Nov 2008 15:49:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Date: Mon, 3 Nov 2008 10:47:50 -0500 Message-ID: Thread-Topic: [mpls] Poll for MPLS-TP documents to become mpls working groupdocuments Thread-Index: Ack9vMqvzRuqx0AQToiUtY5hN6mruwACtm2w From: "Zafar Ali (zali)" To: "Loa Andersson" , , "pwe3" , "L2VPN" , "ccamp" , , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2541; t=1225727307; x=1226591307; c=relaxed/simple; s=rtpdkim1001; 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=20[mpls]=20Poll=20for=20MPLS-TP=20documen ts=20to=20become=20mpls=20working=20groupdocuments |Sender:=20 |To:=20=22Loa=20Andersson=22=20,=20,=20=22pwe3=22=20,=0A=20=20=20=20=20=20=20= 20=22L2VPN=22=20,=20=22ccamp=22=20,=0A=20=20=20=20=20=20=20=20,=20< mpls-tp@ietf.org>; bh=dSJ0yOw52Vw8rXs75LMFQ8YiUwKPlN+ZW3lKtYHpjZc=; b=Bf0MRjQ7JZHF6Aanj3VqKvjH7n4FieBVCcBjYh4RF6jiPiZGtIDSaQ9tg9 UM8mWwDSp1GMSh+R7rO7L5F/Cwe0dcqDNvPahz1Xtmi6wY6nARQv+JXUwdB5 1V3yPHb+uQ; Authentication-Results: rtp-dkim-1; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Hi Loa-=20 In favor for all drafts to become WG docs.=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Monday, November 03, 2008 9:00 AM > To: mpls@ietf.org; pwe3; L2VPN; ccamp; ahtmpls@itu.int;=20 > mpls-tp@ietf.org > Subject: [mpls] Poll for MPLS-TP documents to become mpls=20 > working groupdocuments >=20 > Working group(s) >=20 > we have four documents from the MPLS-TP effort that the=20 > authors think are ready to become working group documents.=20 > The documents are listed below. >=20 > This mail initiate a two week working poll for comments on=20 > three of the documents, for the fourth document > (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. >=20 > Please send your comments before Nov 11 for=20 > draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- >=20 > *Note:* > Please send your responses to the *mpls working group mailing=20 > list*, a bit of discipline is needed, "replay all" won't do=20 > the trick ;). >=20 > Comments Nov 11 the latest: >=20 > Title : MPLS Generic Associated Channel > Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, > R. Aggarwal > Filename : draft-bocci-mpls-tp-gach-gal-00.txt > Pages : 16 > Date : 2008-10-27 >=20 >=20 > Comments Nov 17 the latest: >=20 > Title : MPLS-TP Requirements > Author(s): B. Niven-Jenkins, et al. > Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt > Pages : 18 > Date : 2008-10-31 >=20 > Title : A Framework for MPLS in Transport Networks > Author(s): M. Bocci, S. Bryant > Filename : draft-blb-mpls-tp-framework-01.txt > Pages : 27 > Date : 2008-10-31 >=20 > Title : Requirements for OAM in MPLS Transport Networks > Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi > Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt > Pages : 16 > Date : 2008-11-1 >=20 > Loa and George >=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: Mon, 03 Nov 2008 15:12:04 +0000 Message-ID: <955F6D91F9074267920C29ABF7E129EE@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft agenda Date: Mon, 3 Nov 2008 15:10:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Based on requests received and a few additional things we think ought to be covered, we have put together a DRAFT agenda which you can see at http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm Comments please. Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Nov 2008 14:03:15 +0000 Message-ID: <490F03D6.30408@pi.nu> Date: Mon, 03 Nov 2008 14:59:50 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3 , L2VPN , ccamp , "ahtmpls@itu.int" , "mpls-tp@ietf.org" Subject: Poll for MPLS-TP documents to become mpls working group documents Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Working group(s) we have four documents from the MPLS-TP effort that the authors think are ready to become working group documents. The documents are listed below. This mail initiate a two week working poll for comments on three of the documents, for the fourth document (draft-bocci-mpls-tp-gach-gal-00.txt) we already have an ongoing poll. Please send your comments before Nov 11 for draft-bocci-mpls-tp-gach-gal-00.txt and Nov 17 for the other three- *Note:* Please send your responses to the *mpls working group mailing list*, a bit of discipline is needed, "replay all" won't do the trick ;). Comments Nov 11 the latest: Title : MPLS Generic Associated Channel Author(s): M. Vigoureux, M. Bocci, D. Ward, G. Swallow, R. Aggarwal Filename : draft-bocci-mpls-tp-gach-gal-00.txt Pages : 16 Date : 2008-10-27 Comments Nov 17 the latest: Title : MPLS-TP Requirements Author(s): B. Niven-Jenkins, et al. Filename : draft-jenkins-mpls-mpls-tp-requirements-01.txt Pages : 18 Date : 2008-10-31 Title : A Framework for MPLS in Transport Networks Author(s): M. Bocci, S. Bryant Filename : draft-blb-mpls-tp-framework-01.txt Pages : 27 Date : 2008-10-31 Title : Requirements for OAM in MPLS Transport Networks Author(s): M. Vigoureux, D. Ward, M. Betts, M. Bocci, I.Busi Filename : draft-vigoureux-mpls-tp-oam-requirements-01.txt Pages : 16 Date : 2008-11-1 Loa and George -- 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: Mon, 03 Nov 2008 00:32: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-confirm-data-channel-status-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103003001.C7A5F3A6A12@core3.amsl.com> Date: Sun, 2 Nov 2008 16:30:01 -0800 (PST) --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-02.txt Pages : 15 Date : 2008-11-02 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-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-confirm-data-channel-status-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-02162726.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Nov 2008 19:04:57 +0000 Message-ID: <382FB452E844407982AC4889177536B7@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , Subject: Re: MRN ext. doc Date: Sun, 2 Nov 2008 19:03:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hello again, >>>>>> 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. [SNIP] >>> can u please use the ietf terminology at least to make the point >>> understandable to me (excuse my ignorance). what is a mapped >>> server ? >> >> OK. Well, I did try to explain in my previous response. [SNIP] > ok, i think i barely understood where you are heading at. now what is > the issue with the doc. ? honnestly, i do not catch the point you are > trying to make: section 4 addresses purely signaling procedure issue > (complements existing FA triggering/selection rules) and section 5 a > well-known TE problem that is how to attract traffic when no bearer is > setup (it is a particular case of the generic unknown adjcacency > problem). I didn't actually say there was anything wrong with the document :-) I just asked what I hoped was a simple question. >From our discussion it looks like the answer to my question was "yes". Let's move on. >>>>>> === >>>>>> 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. >>>> >>>> It doesn't make sense to use 11bbbbbb. [SNIP] >>> 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. >> >> I spoke to Lou. >> He had suggested 11bbbbbb because he thought the object might >> end up on a Path message. However, we don't think this would >> actually be the case because the call request message is a Notify. >> So he is more relaxed about this changing to 0bbbbbbb > > are call attributes mandatorily associated to calls (and which case > one could simply mandate support of the related attribute) and their > messaging/processing a must have feature of the protocol ? ... just to > be clear 0bbbbbbb does not solve the former. No, the Call_Attributes object is not mandatory on a Call request message (as currently defined). And yes, you are right, using 0bbbbbbb would not make it mandatory anyway. I am *only* concerned by how the call recipient will process the Notify, how (if?) they will respond, and whether this will waste processing in the network, especially at the call recipient. >>>>>> === >>>>>> 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. [SNIP] >>>> 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? >>> >>> 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 >> >> I agree completely. >> And that was my point. >> The call is a negotiation between end points about what >> connection will be set up, what adaptions will be applied, >> and what TE link will be created. >> This effectively requires the call request to state the set >> of potential adaptations, and the call response to identify >> the subset of acceptable adaptations. The connection can >> then be signaled in the correct switching type, and the >> resulting LSP can be associated to the TE link. > > per 4974, the LINK_CAPABILITY object can be used for > this purpose with subobject Type 65. > > i did not mention it for two reasons a) it is implicit in the > context (a Virtual Link by definition addresses the lowest SC > value) and b) part of the procedure referenced by this doc. Weeeeell... That use of Link Capability is not particularly clear in RFC 4974. According to section 4.3.3. of RFC 4974 this function allows the call initiator to list a set of switching capablities for links that connect it "to the network", and for the responder to reduce the list to those switching capablities that it supports. That is only half the function required. We also need to let the call responder know that we intend using the LSP to support a connection in a particular client layer/region. In other words, we have to specify what adaptation function we want the responder to support. It would be enough to add to the information already carried in the Link_Capablity object the link capability we intend to create. This could go in either the Link_Capablity object or in the Call_Attributes object. Oh, by the way, Link_Capability uses a CNum of type 0bbbbbb A Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Nov 2008 18:26:46 +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: Sun, 2 Nov 2008 19:24:05 +0100 Message-ID: <00275A5B436CA441900CB10936742A38014BA566@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: MRN ext. doc Thread-Index: Ack9D7yCOPB7Oj16RRmWxD55Lc9zfgAAXFgg From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , =20 Hi adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Sunday, November 02, 2008 6:23 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: MRN ext. doc >=20 > Hi Dimitri, >=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. > >>> 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. ... > > > > ok - you would like a ref. to 5339. >=20 > Yes. But not just a simple ref to the doc, but a ref to each of the=20 > unanswered requirements in 5339 this is what i meant. > >>>> =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. > >> > >> 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. > > > > can u please use the ietf terminology at least to make the point > > understandable to me (excuse my ignorance). what is a mapped > > server ? >=20 > OK. Well, I did try to explain in my previous response. >=20 > In the mapped server model, a connection in used in the=20 > server layer/region=20 > in response to a specific demand for end-to-end connectivity=20 > in the client=20 > layer/region. In most cases, the server connection is created=20 > on-demand when=20 > the client connection request reaches the layer boundary. The client=20 > connection is "mapped" to the server connection using the adaptation=20 > function at the boundary node to provide continuous=20 > end-to-end connectivity.=20 > The server connection is not made into a link in the client=20 > layer/region=20 > because its purpose is only to server the current client=20 > connection. When=20 > the client connection is torn down, the server connection=20 > will normally be=20 > torn down as well. >=20 > The many-to-one mapped server case is initiated in the same=20 > way, but it may=20 > be that it is actually possible to map more than one client=20 > connection to=20 > the server connection (effectively there is multiplexing in=20 > the adaptation=20 > function). However, since the server connection is not=20 > advertised as a link=20 > in the client layer/region, the second client connection to=20 > be requested=20 > behaves exactly the same except that the border node can=20 > (before setting up=20 > a new on-demand server connection) note that there is=20 > available capacity on=20 > an existing server connection and use that. >=20 > I suppose that the mapped server cases equate to the creation=20 > of a data link=20 > that is not advertised (i.e. remains as a local client=20 > layer/region link=20 > across the server layer/region). The case where a TE link is=20 > created and=20 > advertised equates to the ITU's Multiplexed Server model. ok, i think i barely understood where you are heading at. now what is the issue with the doc. ? honnestly, i do not catch the point you are trying to make: section 4 addresses purely signaling procedure issue (complements existing FA triggering/selection rules) and section 5 a well-known TE problem that is how to attract traffic when no bearer is setup (it is a particular case of the generic unknown adjcacency problem). > >>>> 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. > > > > not sure. at the end the question is an attribute object class a > > criteria for which rejection is expected. going one step=20 > 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=20 > 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=20 > way around. >=20 > I spoke to Lou. > He had suggested 11bbbbbb because he thought the object might=20 > end up on a=20 > Path message. However, we don't think this would actually be the case=20 > because the call request message is a Notify. > So he is more relaxed about this changing to 0bbbbbbb are call attributes mandatorily associated to calls (and which case one could simply mandate support of the related attribute) and their messaging/processing a must have feature of the protocol ? ... just to be clear 0bbbbbbb does not solve the former. > >> 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 >=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 > >>> 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=20 > 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? > > > > assume a base virtual TE link [PSC,PSC] and the two link=20 > sequence that > > can be followed by the FA-LSP are either=20 > [PSC,LSC]..[LSC,LSC]..[LSC,PSC] > > or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association=20 > between the TE > > link and LSP that determines to which FA that TE link is=20 > now related to >=20 > I agree completely. > And that was my point. > The call is a negotiation between end points about what=20 > connection will be=20 > set up, what adaptions will be applied, and what TE link will=20 > be created.=20 > This effectively requires the call request to state the set=20 > of potential=20 > adaptations, and the call response to identify the subset of=20 > acceptable=20 > adaptations. The connection can then be signaled in the=20 > correct switching=20 > type, and the resulting LSP can be associated to the TE link. per 4974, the LINK_CAPABILITY object can be used for this purpose with subobject Type 65.=20 i did not mention it for two reasons a) it is implicit in the context (a Virtual Link by definition addresses the lowest SC value) and b) part of the procedure referenced by this doc. > >>>> =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. > >> > >> Thanks. > >> > >> Now since there is an aggregate duplication of information > > > > where do you see the "duplication" of information b/w IACD=20 > and ISCD ? >=20 > Well, in the ISCD I see a list of bandwidths available per priority. > In the IACD I see a list of bandwidths available per priority. >=20 > Clearly there is some relationship between these numbers=20 > because they refer=20 > to the same advertised link. >=20 > I don't suppose that the sum of the priority 1 bandwidths for=20 > all IACDs is=20 > supposed to equal the advertised priority 1 bandwidth from=20 > the ISCD. But if=20 > the priority 1 bandwidths for one IACD was larger than that=20 > for the ISCD it=20 > would be strange (meaningless?). >=20 > There is not a direct duplication of information, but there=20 > is some overlap=20 > of information and I am asking how it is resolved. there is no overlap of information too. the IACD is a mean to advertize adjustment capacity between two SC (so, by def. internal) that would otherwise be unknown and thus result in LSP blocking when crossing that LSR. i can give certain base rules of thumb for setting up values of IACD and its accounting (that is similar per nature to current Max LSP Bw) as part of the next revision but this is not going to prevent mis-configuration and/or misuse. -d. > A=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Nov 2008 17:26:26 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , Subject: Re: MRN ext. doc Date: Sun, 2 Nov 2008 17:23:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Dimitri, >>>> === >>>> 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. ... > > ok - you would like a ref. to 5339. Yes. But not just a simple ref to the doc, but a ref to each of the unanswered requirements in 5339 >>>> === >>>> 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. > > can u please use the ietf terminology at least to make the point > understandable to me (excuse my ignorance). what is a mapped > server ? OK. Well, I did try to explain in my previous response. In the mapped server model, a connection in used in the server layer/region in response to a specific demand for end-to-end connectivity in the client layer/region. In most cases, the server connection is created on-demand when the client connection request reaches the layer boundary. The client connection is "mapped" to the server connection using the adaptation function at the boundary node to provide continuous end-to-end connectivity. The server connection is not made into a link in the client layer/region because its purpose is only to server the current client connection. When the client connection is torn down, the server connection will normally be torn down as well. The many-to-one mapped server case is initiated in the same way, but it may be that it is actually possible to map more than one client connection to the server connection (effectively there is multiplexing in the adaptation function). However, since the server connection is not advertised as a link in the client layer/region, the second client connection to be requested behaves exactly the same except that the border node can (before setting up a new on-demand server connection) note that there is available capacity on an existing server connection and use that. I suppose that the mapped server cases equate to the creation of a data link that is not advertised (i.e. remains as a local client layer/region link across the server layer/region). The case where a TE link is created and advertised equates to the ITU's Multiplexed Server model. >>>> 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. > > 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. I spoke to Lou. He had suggested 11bbbbbb because he thought the object might end up on a Path message. However, we don't think this would actually be the case because the call request message is a Notify. So he is more relaxed about this changing to 0bbbbbbb >> 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? > > 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 I agree completely. And that was my point. The call is a negotiation between end points about what connection will be set up, what adaptions will be applied, and what TE link will be created. This effectively requires the call request to state the set of potential adaptations, and the call response to identify the subset of acceptable adaptations. The connection can then be signaled in the correct switching type, and the resulting LSP can be associated to the TE link. >>>> === >>>> 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 an aggregate duplication of information > > where do you see the "duplication" of information b/w IACD and ISCD ? Well, in the ISCD I see a list of bandwidths available per priority. In the IACD I see a list of bandwidths available per priority. Clearly there is some relationship between these numbers because they refer to the same advertised link. I don't suppose that the sum of the priority 1 bandwidths for all IACDs is supposed to equal the advertised priority 1 bandwidth from the ISCD. But if the priority 1 bandwidths for one IACD was larger than that for the ISCD it would be strange (meaningless?). There is not a direct duplication of information, but there is some overlap of information and I am asking how it is resolved. A Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Nov 2008 21: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-path-key-ero-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081101210001.782763A6AB3@core3.amsl.com> Date: Sat, 1 Nov 2008 14:00:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : RSVP Extensions for Path Key Support Author(s) : R. Bradford, J. Vasseur, A. Farrel Filename : draft-ietf-ccamp-path-key-ero-02.txt Pages : 14 Date : 2008-11-1 The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation. This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-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-path-key-ero-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-1134915.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Nov 2008 21:02:30 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081101210001.7BAB13A6AC2@core3.amsl.com> Date: Sat, 1 Nov 2008 14:00:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Ethernet Traffic Parameters Author(s) : D. Papadimitriou, I. Property Filename : draft-ietf-ccamp-ethernet-traffic-parameters-06.txt Pages : 13 Date : 2008-11-1 This document describes the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-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-ethernet-traffic-parameters-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-1135317.I-D@ietf.org> --NextPart--