From owner-ccamp@ops.ietf.org Sun May 1 17:54:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18892 for ; Sun, 1 May 2005 17:54:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSMba-0003iN-OX for ccamp-archive@ietf.org; Sun, 01 May 2005 18:08:04 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DSMFX-000E6T-9d for ccamp-data@psg.com; Sun, 01 May 2005 21:45:15 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DSMFU-000E3m-7u; Sun, 01 May 2005 21:45:12 +0000 Received: from du-069-0027.access.clara.net ([217.158.132.27] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DSMFR-0003KT-9E; Sun, 01 May 2005 22:45:10 +0100 Message-ID: <07e301c54e97$561f3080$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: , , "Scott Bradner" , "'Kireeti Kompella'" , , "Bill Fenner" Subject: Liaison to ITU-T Q14/15 on The Evaluation of IETF Routing Protocols in the Context of ASON Date: Sun, 1 May 2005 22:46:19 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit To: Kam Lam, Rapporteur of ITU-T Question 14/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: The Evaluation of IETF Routing Protocols in the Context of ASON Routing Requirements For: Action Deadline: 30th May 2005 Dear Kam, As you will be aware a Design Team has been working to evaluate the existing IP-based routing protocols with a view to discovering their applicability to the requirements of the ASON architecture and establishing what, if any, protocol extensions are required. This design team operates under the umbrella of the CCAMP working group within the IETF and is made up of people drawn equally from the IETF and ITU-T communities. The purpose of this liaison is to make you aware of the progress of the Design Team, and to solicit input from Q14/15 in the form of review feedback on the latest output of the Design Team which can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt. The CCAMP working group will soon consider collaborating with other IETF working groups within the Routing Area to provide adequate solutions for the identified ASON routing capabilities. Best regards, Adrian Farrel and Kireeti Kompella From owner-ccamp@ops.ietf.org Sun May 1 18:02:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19269 for ; Sun, 1 May 2005 18:02:41 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSMjz-0003qb-Gq for ccamp-archive@ietf.org; Sun, 01 May 2005 18:16:44 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DSMNQ-000FCs-0L for ccamp-data@psg.com; Sun, 01 May 2005 21:53:24 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DSMNP-000FCT-AA; Sun, 01 May 2005 21:53:23 +0000 Received: from du-069-0027.access.clara.net ([217.158.132.27] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DSMNN-0005ua-9d; Sun, 01 May 2005 22:53:22 +0100 Message-ID: <07ef01c54e98$7b755610$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: , "'Kireeti Kompella'" , , "Bill Fenner" , "Scott Bradner" , References: <037e01c524d7$0a7a8f60$a4858182@Puppy> Subject: Response Liaison to Q14/15 on Transport use of LMP Date: Sun, 1 May 2005 22:53:45 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit To: Kam Lam, Rapporteur of ITU-T Question 14/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: Response to your Liaison on the Transport Use of LMP For: Information Dear Kam, Thank you for your liaison from Q14/15 dated 9th March 2005 including several observations on the SNPP link construct and the way in which adaptation/termination properties are defined and used in the ASON architecture. This is useful and timely information since it fits with work being done by several members of CCAMP to evaluate and resolve issues associated with multi-region and multi-layer networks. We will make sure that the information is passed along to them. Best regards, Adrian Farrel and Kireeti Kompella From owner-ccamp@ops.ietf.org Sun May 1 18:06:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19663 for ; Sun, 1 May 2005 18:06:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSMnI-0003u0-IF for ccamp-archive@ietf.org; Sun, 01 May 2005 18:20:08 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DSMVV-000Gt0-RZ for ccamp-data@psg.com; Sun, 01 May 2005 22:01:45 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DSMVT-000GsR-2I; Sun, 01 May 2005 22:01:43 +0000 Received: from du-069-0027.access.clara.net ([217.158.132.27] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DSMVR-0008Wx-82; Sun, 01 May 2005 23:01:42 +0100 Message-ID: <07f401c54e99$a53369a0$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: , "'Kireeti Kompella'" , , "Bill Fenner" , "Scott Bradner" , Subject: Liaison to Q14/15 on the GMPLS / ASON Lexicography Date: Sun, 1 May 2005 23:01:55 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit To: Kam Lam, Rapporteur of ITU-T Question 14/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: GMPLS / ASON Lexicography For: Action Deadline: 30th May 2005 Dear Kam, As you will be aware, the CCAMP working group took the output of the very useful terminology discussions held under your auspices in Holmdel earlier this year and created an Internet-Draft to capture and progress the information. The most up-to-date version of this draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt Since this work is heavily dependent on the definition of terms within the ASON architecture, and since much of the text was taken directly from material dictated by Q14/15 participants in Holmdel, we would greatly appreciate it if Q14/15 was able to provide further review input at this stage. As usual, review input in the return of a response liaison is very acceptable, but individuals who wish to contribute to this work further may discuss the draft on the CCAMP mailing list (see http://www.ietf.org/html.charters/ccamp-charter.html) Best regards, Adrian Farrel and Kireeti Kompella From owner-ccamp@ops.ietf.org Sun May 1 18:14:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20558 for ; Sun, 1 May 2005 18:14:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSMvG-00041B-2f for ccamp-archive@ietf.org; Sun, 01 May 2005 18:28:22 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DSMbn-000Iuv-9B for ccamp-data@psg.com; Sun, 01 May 2005 22:08:15 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DSMbl-000Itl-Gp; Sun, 01 May 2005 22:08:13 +0000 Received: from du-069-0027.access.clara.net ([217.158.132.27] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DSMbi-000A4j-9Q; Sun, 01 May 2005 23:08:11 +0100 Message-ID: <080101c54e9a$8d51b700$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Hiroshi Ohta" Cc: "'Kireeti Kompella'" , , "Bill Fenner" , "Scott Bradner" , , References: <13f501c535e5$b40d2370$dccb2bd4@Puppy> Subject: Response Liaison to Q3/15 on the GMPLS/ASON Lexicography Date: Sun, 1 May 2005 23:10:10 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit To: Hiroshi Ohta, Rapporteur of ITU-T Question 3/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: GMPLS / ASON Lexicography For: Information Dear Ohta_san, Thank you for liaising a copy of G.8081 to the IETF CCAMP working group. This has been most useful in the preparation of the latest version of our Internet-Draft that provides a mapping from common GMPLS terms to ASON terminology. The most recent version of this draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt. I must apologise that the current version does not include a reference to G.8081 - this will be remedied in the next revision. We are assuming that most input from SG15 for this draft will come from Q14/15 and have liaised the draft to them for their review. However, if participants in Q3/15 have any comments on the draft we would be very pleased to receive them either in a response liaison or as individual emails on the CCAMP mailing list (see http://www.ietf.org/html.charters/ccamp-charter.html). Best regards, Adrian Farrel and Kireeti Kompella From owner-ccamp@ops.ietf.org Mon May 2 00:02:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08713 for ; Mon, 2 May 2005 00:02:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSSMR-0000Jm-Mz for ccamp-archive@ietf.org; Mon, 02 May 2005 00:16:52 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DSRzL-000MZD-G3 for ccamp-data@psg.com; Mon, 02 May 2005 03:52:55 +0000 Received: from [216.136.174.114] (helo=smtp017.mail.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DSRzC-000MXY-Gr for ccamp@ops.ietf.org; Mon, 02 May 2005 03:52:46 +0000 Received: from unknown (HELO RLAPTOP) (vsharma87@221.128.174.28 with login) by smtp017.mail.yahoo.com with SMTP; 2 May 2005 03:52:42 -0000 Reply-To: From: "Vishal Sharma" To: "ccamp mailing list" , "ccamp chair" , "ccamp chair" Cc: "Alex Zinin" , "Greg Bernstein" , "Eric Mannie" , "Eric W. Gray" Subject: RE: Document Action: 'Framework for GMPLS-based Control of SDH/SONET Networks' to Informational RFC Date: Sun, 1 May 2005 20:52:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: High In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.0 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Hi Adrian, Just wanted to be sure what the next step is on this? Are the author's required to make the changes suggested by the RFC Editor and submit another version? If so, to whom and by when? Thanks, -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of The IESG > Sent: Friday, April 29, 2005 8:23 AM > To: IETF-Announce > Cc: Internet Architecture Board; RFC Editor; ccamp mailing list; ccamp > chair; ccamp chair > Subject: Document Action: 'Framework for GMPLS-based Control of > SDH/SONET Networks' to Informational RFC > > > The IESG has approved the following document: > > - 'Framework for GMPLS-based Control of SDH/SONET Networks ' > as an Informational RFC > > This document is the product of the Common Control and Measurement Plane > Working Group. > > The IESG contact persons are Alex Zinin and Bill Fenner. > > Technical Summary > > GMPLS consists of a suite of protocol extensions to MPLS to make > these protocols more generally applicable, to include - for example > - control of non-packet based switching, and particularly, optical > switching. One area of prime consideration is to use Generalized > MPLS (GMPLS) protocols in upgrading the control plane of optical > transport networks. This document illustrates this process by > describing those extensions to GMPLS protocols that are directed > towards controlling SDH/SONET networks. SDH/SONET networks make > very good examples of this process since they possess a rich > multiplex structure, a variety of protection/restoration options, > are well defined, and are widely deployed. The document discusses > extensions to GMPLS routing protocols to disseminate information > needed in transport path computation and network operations, > together with the extensions to GMPLS label distribution protocols > needed for the provisioning of transport circuits. New capabilities > that an GMPLS control plane would bring to SDH/SONET networks, such > as new restoration methods and multi-layer circuit establishment, > are also discussed. > > Working Group Summary > > The CCAMP WG had a consensus on advancing this document. > > Protocol Quality > > The document has been reviewed by the RTG area directorate and > Alex Zinin. > > RFC Editor Note > > Section 1.1 para 2 > > OLD > An MPLS network consists of MPLS nodes called Label Switch Routers > (LSRs) connected via circuits called Label Switched Paths (LSPs). An > LSP is unidirectional and could be of several different types such > as point-to-point, point-to-multipoint, and multipoint-to-point. > NEW > An MPLS network consists of MPLS nodes called Label Switch Routers > (LSRs) connected via Label Switched Paths (LSPs). An > LSP is unidirectional and could be of several different types such > as point-to-point, point-to-multipoint, and multipoint-to-point. > > Replace text in section 7 (Security Considerations) with the following. > > NEW: > > The use of a control plane to provision connectivity through a SONET/SDH > network shifts the security burden significantly from the > management plane > to the control plane. Before the introduction of a control plane, the > communications that had to be secured were between the > management stations > (Element Management Systems or Network Management Systems) and each > network element that participated in the network connection. After the > introduction of the control plane, the only management plane > communication > that needs to be secured is that to the head-end (ingress) > network node as > the end-to-end service is requested. On the other hand, the > control plane > introduces a new requirement to secure signaling and routing > communications between adjacent nodes in the network plane. > > The security risk from impersonated management stations is significantly > reduced by the use of a control plane. In particular, where unsecure > versions of network management protocols such as SNMP versions 1 and 2 > were popular configuration tools in transport networks, the use of a > control plane may significantly reduce the security risk of > malicious and > false assignment of network resources that could cause the > interception or > disruption of data traffic. > > On the other hand, the control plane may increase the number of security > relationships that each network node must maintain. Instead of a single > security relationship with its management element, each network > node must > now maintain a security relationship with each of its signaling and > routing neighbors in the control plane. > > There is a strong requirement for singaling and control plane > exchanges to > be secured, and any protocols proposed for this purpose must be > capable of > secure message exchanges. This is already the case for the > existing GMPLS > routing and signaling protocols. > > From darwin@about.com Mon May 2 14:02:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10296 for ; Mon, 2 May 2005 14:02:59 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSfTj-0000so-Es for ccamp-archive@ietf.org; Mon, 02 May 2005 14:17:11 -0400 Received: from cable-66-190-201-124.thb.la.charter.com ([66.190.201.124]) by mx2.foretec.com with smtp (Exim 4.24) id 1DSfFt-0005qJ-Ee for ccamp-archive@ietf.org; Mon, 02 May 2005 14:02:55 -0400 Message-ID: <7fa301c54f40$3286dfe8$3af0b161@about.com> From: "Richard K. Lee" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?TG92ZSBwaWxscyAtIDc1JSBPRkY=?= Date: Mon, 02 May 2005 17:57:05 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_3C29264C.8B1A65FD" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_3C29264C.8B1A65FD Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_0852814F.F6167252" ------=_NextPart_001_0001_0852814F.F6167252 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Full erection Long lasting effects No prescription required 2 popular medicines: CIALIS - http://www.pills-of-love.com/sv/ VIAGRA - http://www.pills-of-love.com/vt/ Discreet packaging _________________________________________________________________________ To stop further mailings, go here _________________________________________________________________________ ------=_NextPart_001_0001_0852814F.F6167252 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Full erection
Long lasting effects
No prescription required

2 popular medicines:
CIALIS - http://www.pills-of-love.com/sv/
VIAGRA - http://www.pills-of-love.com/vt/

Discreet packaging


_________________________________________________________________________
To stop further mailings, go here
_________________________________________________________________________

------=_NextPart_001_0001_0852814F.F6167252-- ------=_NextPart_000_0000_3C29264C.8B1A65FD-- From owner-ccamp@ops.ietf.org Mon May 2 19:29:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29881 for ; Mon, 2 May 2005 19:29:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSkZc-0005c7-FT for ccamp-archive@ietf.org; Mon, 02 May 2005 19:43:37 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DSk9R-0008W5-2z for ccamp-data@psg.com; Mon, 02 May 2005 23:16:33 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DSk9P-0008Vq-5Z for ccamp@ops.ietf.org; Mon, 02 May 2005 23:16:31 +0000 Received: from du-069-0073.access.clara.net ([217.158.132.73] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DSk9N-000EpU-HD for ccamp@ops.ietf.org; Tue, 03 May 2005 00:16:29 +0100 Message-ID: <08d701c54f6d$40b2dae0$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder: Enforcement of Updated IPR Boilerplate Date: Mon, 2 May 2005 22:49:39 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit FYI ----- Original Message ----- From: "IETF Secretariat" Sent: Monday, May 02, 2005 8:42 PM Subject: Reminder: Enforcement of Updated IPR Boilerplate > This message is to remind you that as of Friday, May 6, 2005, > all Internet-Drafts that are submitted to the IETF Secretariat > for posting must include the IPR-related notices and disclaimers > specified in RFC 3978 (BCP 78), "IETF Rights in Contributions." > The required notices and disclaimers can be found in Section 5, > "Notices Required in IETF Documents," of RFC 3978, and in > Section 3, "IPR-Related Notices Required in Internet-Drafts," > of the recently revised "Guidelines to Authors of Internet-Drafts" > (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" > document also provides additional guidance regarding the > placement of these notices. > > Please note that the required notices and disclaimers must > be reproduced verbatim since they have been legally reviewed > and formally adopted as part of the IETF process. The > Secretariat will not accept deviations from the specified > text, nor will it correct the text. Any documents that do > not comply with the requirements of RFC 3978, and with > the most recent version of the "Guidelines" document, will > be returned to the submitter. > > The IETF Secretariat From owner-ccamp@ops.ietf.org Tue May 3 14:42:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19764 for ; Tue, 3 May 2005 14:42:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT2Zl-00018c-I7 for ccamp-archive@ietf.org; Tue, 03 May 2005 14:57:00 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DT2B8-000OFk-V2 for ccamp-data@psg.com; Tue, 03 May 2005 18:31:30 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DT2B7-000OFW-Kz for ccamp@ops.ietf.org; Tue, 03 May 2005 18:31:29 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 03 May 2005 14:44:40 -0400 X-IronPort-AV: i="3.92,151,1112587200"; d="scan'208"; a="47289199:sNHT31553428" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j43IUqeD017552; Tue, 3 May 2005 14:31:13 -0400 (EDT) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:30:52 -0400 Received: from [192.168.1.100] ([10.86.242.105]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:30:51 -0400 In-Reply-To: <006201c53b95$855fa150$6fcb2bd4@Puppy> References: <006201c53b95$855fa150$6fcb2bd4@Puppy> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , "Scott Bradner" , , "Bill Fenner" From: JP Vasseur Subject: Re: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Tue, 3 May 2005 14:31:04 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 03 May 2005 18:30:51.0381 (UTC) FILETIME=[3BD9A250:01C5500E] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Hi, First of all, thanks to the CCAMP WG chair for helping out in the resolution of this issue. The draft represents an important technique which, in our opinion, is a valuable addition to the management and operation of LSPs in MPLS and GMPLS networks especially where those LSPs traverse multiple domains. We have looked at this function carefully, but do not believe that it can be achieved by any other technique that would not also be potentially covered by this IPR disclosure. Therefore we propose the following steps: 1. Text is added to the I-D as follows. The procedures described in this document are the subject of an Intellectual Property Rights claim. For this reason, the procedures are entirely optional within an MPLS or GMPLS network. Implementations that do not support the procedures described in this document will interoperate seamlessly with those that do. Further, an implementation that does not support the procedures described in this document will not be impacted or implicated by a neighboring implementation that does implement the procedures. An ingress implementation that chooses not to support the procedures described in this document may still achieve re-optimization by periodically issuing a speculative make-before-break replacement of an LSP without trying to discovery whether a more optimal path is available in a downstream domain. Such a procedure would not be in conflict with any mechanisms not already documented in [RFC3209] and [RFC3473]. 2. The I-D should be updated with comments arising from the WG last call. 3. The I-D should be progressed as an informational RFC Thanks. JP. On Apr 7, 2005, at 8:52 AM, Adrian Farrel wrote: > Please see below a response from the Counsel for Nortel Networks with > regard to my enquiry about their IPR disclosure for > draft-ietf-ccamp-loose-path-reopt-00.txt. > > The working group must now decide whether it wishes to pursue the > techniques described in the I-D notwithstanding the IPR claim, or > whether > it should seek out an alternative technology. > > Discussion please. > > Thanks, > Adrian > ----- Original Message ----- > From: "Michelle Lee" > To: "Adrian Farrel" > Cc: "'Kireeti Kompella'" ; "Richard Weiss" > > Sent: Wednesday, April 06, 2005 5:54 PM > Subject: RE: Nortel Networks Statement on IPR claimed in > draft-ietf-ccamp-loose-path-reopt-00.txt > > >> Dear Mr. Farrel, >> >> Thank you for your email. >> >> Unfortunately, I am not in a position to answer these questions >> specifically, especially since they would require my providing > privileged >> and/or confidential information. We believe, however, our intentions >> are >> clearly set forth in and by our conforming disclosure and declaration >> statement to IETF with respect to IETF Internet Draft >> draft-ietf-ccamp-loose-path-reopt-00.txt, and that experts in the area > can >> probably better determine relevance of the identified patent therein. >> >> Kind Regards, >> Michelle Lee >> Counsel, IP Law >> Nortel Networks >> >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Monday, March 21, 2005 4:32 PM >> To: weissr@nortelnetworks.com; mleelaw@nortelnetworks.com >> Cc: 'Kireeti Kompella'; ccamp@ops.ietf.org >> Subject: Nortel Networks Statement on IPR claimed in >> draft-ietf-ccamp-loose-path-reopt-00.txt >> >> >> >> Dear Richard and Michelle, >> >> Thank you for submitting your Patent Disclosure >> ( >> > reopt > -0 >> 0.txt> >> > http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path- > reopt-00 >> .txt) >> with respect to IETF Internet Draft >> draft-ietf-ccamp-loose-path-reopt-00.txt. >> >> I would be grateful if you could clarify two points to help me > understand >> this discolsure further. >> >> 1. The disclosure states that: >> Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus and >> method of maintaining timely topology data within a link state > routing >> network" may contain claims that may be necessary for practicing >> a >> resulting IETF Standard based on this Internet Draft. >> Could you provide more detail about what aspects of >> draft-ietf-ccamp-loose-path-reopt-00.txt you believe may be impacted > by >> this disclosure? >> >> 2. Can you clarify whether the "fair, reasonable, reciprocal, and >> non-discriminatory terms" referenced in the disclosure include the >> intention, in the event that the referenced draft becomes an >> Internet >> Standard, not to assert the patent except that some party asserts a >> patent >> patent it owns or controls against Nortel? >> By way of an example of wording that covers this intention, can I > draw >> your attention to a completely unrelated IPR disclosure at >> > >> http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt >> >> Thank you for any clarification you are able to offer. >> >> Please note that I am copying this email to Kireeti Kompella who > co-chairs >> the IETF's CCAMP working group with me. The CCAMP working group > developed >> the Internet-Draft in question > (draft-ietf-ccamp-loose-path-reopt-00.txt) >> and so I am also copying this email to the CCAMP mailing list. >> >> Best regards, >> Adrian Farrel >> -- >> Adrian Farrel >> Old Dog Consulting >> Phone: +44 (0) 1978-860944 >> Fax: +44 (0) 870-130-5411 >> adrian@olddog.co.uk >> >> >> >> > From owner-ccamp@ops.ietf.org Thu May 5 16:36:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11406 for ; Thu, 5 May 2005 16:36:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnJV-0006ZV-BO for ccamp-archive@ietf.org; Thu, 05 May 2005 16:51:18 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DTmt8-000GFz-05 for ccamp-data@psg.com; Thu, 05 May 2005 20:24:02 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTmt7-000GFl-6c for ccamp@ops.ietf.org; Thu, 05 May 2005 20:24:01 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08958; Thu, 5 May 2005 16:23:57 -0400 (EDT) Message-Id: <200505052023.QAA08958@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-00.txt Date: Thu, 05 May 2005 16:23:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : Addressing and Messaging in Generalized Multi-Protocol Label Switching (GMPLS) Networks Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-gmpls-addressing-00.txt Pages : 17 Date : 2005-5-5 This document explains and clarifies addressing and messaging in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSR) based on experience gained in deployments and interoperability testing and proper interpretation of published RFCs. The document recommends a proper approach for the interpretation and choice of address and identifier fields within GMPLS protocols and references specific control plane usage models. It also examines some common GMPLS Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling message processing issues and recommends solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-addressing-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-addressing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-5160822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-addressing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-5160822.I-D@ietf.org> --OtherAccess-- --NextPart-- From 2ira@about.com Thu May 5 17:37:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22109 for ; Thu, 5 May 2005 17:37:40 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToGn-0002wP-Us for ccamp-archive@ietf.org; Thu, 05 May 2005 17:52:35 -0400 Received: from cpe000ae65dd91c-cm013459902297.cpe.net.cable.rogers.com ([24.157.128.102]) by mx2.foretec.com with smtp (Exim 4.24) id 1DTo2O-00049L-At for ccamp-archive@ietf.org; Thu, 05 May 2005 17:37:41 -0400 Message-ID: <646d01c551b8$fe29f577$87cb0669@about.com> From: "TJ Meds Ltd." <2ira@about.com> To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?WGFuYXggLSA3NSUgT0ZG?= Date: Thu, 05 May 2005 21:21:16 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_AAC74D8E.B2BDC401" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_AAC74D8E.B2BDC401 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_FC76F934.D807C754" ------=_NextPart_001_0001_FC76F934.D807C754 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit VALIUM - $1.10/pill XANAX - $1.07/pill http://www.popularmeds.biz Anti-Depressants: Paxil, Prozac, Zoloft Pain Relief: Celebrex, Soma, Vioxx Weight Loss: Meridia, Xenical Other: Levitra, Propecia, Ambien _________________________________________________________________________ To stop further mailings, go here _________________________________________________________________________ ------=_NextPart_001_0001_FC76F934.D807C754 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

VALIUM - $1.10/pill
XANAX - $1.07/pill

http://www.popularmeds.biz

Anti-Depressants: Paxil, Prozac, Zoloft
Pain Relief: Celebrex, Soma, Vioxx
Weight Loss: Meridia, Xenical
Other: Levitra, Propecia, Ambien


_________________________________________________________________________
To stop further mailings, go here
_________________________________________________________________________

------=_NextPart_001_0001_FC76F934.D807C754-- ------=_NextPart_000_0000_AAC74D8E.B2BDC401-- From owner-ccamp@ops.ietf.org Fri May 6 15:55:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00839 for ; Fri, 6 May 2005 15:55:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU99D-0005ay-7W for ccamp-archive@ietf.org; Fri, 06 May 2005 16:10:09 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DU8jp-000I89-Td for ccamp-data@psg.com; Fri, 06 May 2005 19:43:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DU8jn-000I7p-Gu for ccamp@ops.ietf.org; Fri, 06 May 2005 19:43:53 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28973; Fri, 6 May 2005 15:43:48 -0400 (EDT) Message-Id: <200505061943.PAA28973@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-02.txt Date: Fri, 06 May 2005 15:43:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --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 : A Transport Network View of the Link Management Protocol Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-transport-lmp-02.txt Pages : 17 Date : 2005-5-6 The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-transport-lmp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-6153147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-transport-lmp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-6153147.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu May 12 17:48:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12451 for ; Thu, 12 May 2005 17:48:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWLo1-0007BW-EB for ccamp-archive@ietf.org; Thu, 12 May 2005 18:05:21 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWLOb-000DLn-IP for ccamp-data@psg.com; Thu, 12 May 2005 21:39:05 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWLOa-000DLY-Gp for ccamp@ops.ietf.org; Thu, 12 May 2005 21:39:04 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 12 May 2005 14:39:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4CLcHni020503; Thu, 12 May 2005 14:39:01 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 14:39:00 -0700 Received: from [10.21.122.158] ([10.21.122.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 14:38:59 -0700 Message-ID: <4283CCF2.3030306@cisco.com> Date: Thu, 12 May 2005 14:38:58 -0700 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, Reshad Rahman , "Arun Satyanarayana (asatyana)" Subject: Re: Working group last call on draft-ietf-ccamp-rsvp-restart-ext-02.txt References: <069301c54cba$10249c70$1c849ed9@Puppy> <004b01c556ef$1b2be080$c1849ed9@Puppy> In-Reply-To: <004b01c556ef$1b2be080$c1849ed9@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2005 21:39:00.0039 (UTC) FILETIME=[0221E570:01C5573B] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Adrian, Thanks for the comments. Will update the I-D and respin. Thanks, Arun =============================================================== Adrian Farrel wrote: > Hi, > > I have some comments on this draft > > Please fix the boilerplate. The Secretariat are now policing this tightly > and will fail any future submissions. You would do well to run idnits over > any future version before submitting it. > > Please indicate at the head of the I-D what the intended category of the > draft is. Presumably Standards Track. > > Do you believe that this I-D updates RFC3473? If so, please put this in > the header of the draft. > Ditto RFC2961. > > There are some instances of "should" / "should not" / "must" / > 'recommended" in lower case. Please be careful that you mean this. > > Abstract uses two acronyms (ERO and LSP) without expanding them. > > Introduction > I fell that it would be helpful to state why we are working on graceful > restart. Probably by expaning the first sentence to say very briefly what > graceful restart actually is. Something like "to synchronize the control > plane state of a restarting control plane component with the data plane > state that has been preserved, carrying user traffic during the control > plan component downtime." > > Introduction (and throughout) > You talk about a restarting "node", but I think you really mean a > restarting control plane signaling component (often called a signaling > controller). It is helpful to distinguish the control plane from the data > plane for graceful restart, and I think that the term "node" does not > help. > I appreciate that RFC3473 uses the term "nodal fault". > Maybe you can make a terminology statement at the top of the I-D to the > effect that where you say "node" you are generally refering to the > signaling controller for the data plane switch. > > Section 2.3 Transmission of RecoveryPath messages > There is a slight contradiction or confusion here. > First, the text says that the downstream neighbor "should spread the > messages across 1/2 the Recovery Time interval." But then it points out > that retransmission may be required with up to three retransmissions, and > says... "the period between re-send attempts SHOULD be such that at least > 3 attempts are completed before the expiry of 1/2 the Recovery Time > interval." > This implies that (if the Message ID mechanim is not in use) the > downstream neighbor SHOULD spread the messages across 1/6 the Recovery > Time interval. > But see also section 3.3.1 where the Srefreshes are sent for the first > time over 1/4 of the interval and may also be retransmitted (presumably up > to 3 times). > > Sections 2.4.1, 2.4.2, 3.3.2 (twice) > s/triggered Path/trigger Path/ > > Section 2.4.3 > Twice in this section you give "SHOULD" actions regarding the discard of > partial state. What are the implications of not following this advice? Why > is it not "MUST"? > > Section 3.2.2 > "There are no compatibility issues introduced in this section." > You probably mean "in the procedures defined in section 3.2.1." > > Section 3.3, 3.3.1 (including title), and 3.3.2 (including title) > Several instances of "RecoveryPath-related Srefresh message" can be > reduced to ""RecoveryPath Srefresh message" > > Section 3.3.1 > "A neighbor of a restarting node generates one or more" > Is this "MAY", "SHOULD" or "MUST"? > > Section 3.3.1 > Please be very careful to say "RecoveryPath Srefresh" every time you mean > it, because normal Srefresh processing may continue in parallel. Otherwise > your text will be interpretted to mean that normal Srefresh is broken. In > fact, you should make clear that these procedures do no impact normal > Srefresh processing. > > Section 3.3.2 > See the timing comments for section 2.3. > Here you say... > The restarted node MAY spread the transmission of > such triggered Path messages across 1/2 of the remaining Recovery > Period to allow the downstream RSVP neighbor sufficient processing > time. > Do you mean, up until the end of the 3rd quarter, or do you mean for each > Path message, spread over half of the remaining time to the end of the > whole interval? > > Section 5 > If an outside influence is able to cause the control plane of a node to go > down and come up again, this will obviously impact the controllability of > the LSPs that transit that node. Your procedures restore the ability to > control those LSPs and so they have a positive influence on security, and > you should say so. > On the other hand, your procedures impact the neighboring upstream nodes > and cause them to perform increased processing possibly to the detrement > of their handling of other control plane messages. Thus, by toggling one > node I can impact LSPs that do not transit that node. You need to flag > this and point out that it is handled by setting the Recovery Time > sufficiently large. > > Section 6 > This section is very weak! > Could you please name the objects/messages and point to the sections where > they are defined. > The object is not "of form 10bbbbbb". That is the form of the C-Num. > > Section 6 > So you think there is a need for IANA to track the bit allocations in the > Flags field of the Message_ID List object? > > Section 7.2 > You might want to consider removing this reference since the I-D is, I > think, expired without any intention of being regenerated. > > Section 11 > The year is now 2005 :-) > > Thanks, > Adrian From info@mail.kqsv07.com Thu May 12 19:45:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21243 for ; Thu, 12 May 2005 19:45:40 -0400 (EDT) Received: from [211.240.63.85] (helo=mail.kqsv07.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DWNcx-0001Mu-Uh for ccamp-archive@ietf.org; Thu, 12 May 2005 20:02:05 -0400 Received: (qmail 12142 invoked by uid 508); 12 May 2005 22:07:28 +0900 Date: 12 May 2005 22:07:28 +0900 Message-ID: <20050512130728.12140.qmail@mail.kqsv07.com> From: info@kqsv07.com To: ccamp-archive@ietf.org Subject: 新規登録の方は10000円分無料 X-Spam-Score: 3.5 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 一万円分！完全無料で使用OK ■今なら間に合うWチャンス！無料ポイントアップ楽しさ100倍！■ ※登録女性会員のジャンル別人気ランキング 一位：逆援（189名登録） 二位：援交（429名登録） 三位：SM逆援（243名登録） 四位：セフレ（1038名登録） 五位：不倫（2421名登録） 六位：テレエッチ（3463名登録） ・ ・ ・ 一万円分完全無料でお試しは ↓↓↓ http://awg.webchu.com/?summer7 只今！新規登録した方には無料で10,000円分ご利用出来ます。 【無料ポイント内で十分にパートナーを探す事が出来ます。】 ※18歳以上の秘密厳守できる方なら何方でも利用OK ↓↓入口↓↓ CLICK http://awg.webchu.com/?summer7 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ※18歳未満のご利用遠慮下さい。 今後、メールの受信を拒否する場合は下記URLに返信下さい。 henshin_senyou@ok.kz From owner-ccamp@ops.ietf.org Fri May 13 00:42:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15943 for ; Fri, 13 May 2005 00:42:13 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWSFx-0004f5-7k for ccamp-archive@ietf.org; Fri, 13 May 2005 00:58:39 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWRrt-000Ivq-32 for ccamp-data@psg.com; Fri, 13 May 2005 04:33:45 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWRrr-000IvM-M0 for ccamp@ops.ietf.org; Fri, 13 May 2005 04:33:44 +0000 Received: from du-069-0480.access.clara.net ([217.158.145.226] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DWCsg-00073y-Is; Thu, 12 May 2005 13:33:37 +0100 Message-ID: <004b01c556ef$1b2be080$c1849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Arun Satyanarayana" , "Reshad Rahman" References: <069301c54cba$10249c70$1c849ed9@Puppy> Subject: Re: Working group last call on draft-ietf-ccamp-rsvp-restart-ext-02.txt Date: Thu, 12 May 2005 13:29:33 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Hi, I have some comments on this draft Please fix the boilerplate. The Secretariat are now policing this tightly and will fail any future submissions. You would do well to run idnits over any future version before submitting it. Please indicate at the head of the I-D what the intended category of the draft is. Presumably Standards Track. Do you believe that this I-D updates RFC3473? If so, please put this in the header of the draft. Ditto RFC2961. There are some instances of "should" / "should not" / "must" / 'recommended" in lower case. Please be careful that you mean this. Abstract uses two acronyms (ERO and LSP) without expanding them. Introduction I fell that it would be helpful to state why we are working on graceful restart. Probably by expaning the first sentence to say very briefly what graceful restart actually is. Something like "to synchronize the control plane state of a restarting control plane component with the data plane state that has been preserved, carrying user traffic during the control plan component downtime." Introduction (and throughout) You talk about a restarting "node", but I think you really mean a restarting control plane signaling component (often called a signaling controller). It is helpful to distinguish the control plane from the data plane for graceful restart, and I think that the term "node" does not help. I appreciate that RFC3473 uses the term "nodal fault". Maybe you can make a terminology statement at the top of the I-D to the effect that where you say "node" you are generally refering to the signaling controller for the data plane switch. Section 2.3 Transmission of RecoveryPath messages There is a slight contradiction or confusion here. First, the text says that the downstream neighbor "should spread the messages across 1/2 the Recovery Time interval." But then it points out that retransmission may be required with up to three retransmissions, and says... "the period between re-send attempts SHOULD be such that at least 3 attempts are completed before the expiry of 1/2 the Recovery Time interval." This implies that (if the Message ID mechanim is not in use) the downstream neighbor SHOULD spread the messages across 1/6 the Recovery Time interval. But see also section 3.3.1 where the Srefreshes are sent for the first time over 1/4 of the interval and may also be retransmitted (presumably up to 3 times). Sections 2.4.1, 2.4.2, 3.3.2 (twice) s/triggered Path/trigger Path/ Section 2.4.3 Twice in this section you give "SHOULD" actions regarding the discard of partial state. What are the implications of not following this advice? Why is it not "MUST"? Section 3.2.2 "There are no compatibility issues introduced in this section." You probably mean "in the procedures defined in section 3.2.1." Section 3.3, 3.3.1 (including title), and 3.3.2 (including title) Several instances of "RecoveryPath-related Srefresh message" can be reduced to ""RecoveryPath Srefresh message" Section 3.3.1 "A neighbor of a restarting node generates one or more" Is this "MAY", "SHOULD" or "MUST"? Section 3.3.1 Please be very careful to say "RecoveryPath Srefresh" every time you mean it, because normal Srefresh processing may continue in parallel. Otherwise your text will be interpretted to mean that normal Srefresh is broken. In fact, you should make clear that these procedures do no impact normal Srefresh processing. Section 3.3.2 See the timing comments for section 2.3. Here you say... The restarted node MAY spread the transmission of such triggered Path messages across 1/2 of the remaining Recovery Period to allow the downstream RSVP neighbor sufficient processing time. Do you mean, up until the end of the 3rd quarter, or do you mean for each Path message, spread over half of the remaining time to the end of the whole interval? Section 5 If an outside influence is able to cause the control plane of a node to go down and come up again, this will obviously impact the controllability of the LSPs that transit that node. Your procedures restore the ability to control those LSPs and so they have a positive influence on security, and you should say so. On the other hand, your procedures impact the neighboring upstream nodes and cause them to perform increased processing possibly to the detrement of their handling of other control plane messages. Thus, by toggling one node I can impact LSPs that do not transit that node. You need to flag this and point out that it is handled by setting the Recovery Time sufficiently large. Section 6 This section is very weak! Could you please name the objects/messages and point to the sections where they are defined. The object is not "of form 10bbbbbb". That is the form of the C-Num. Section 6 So you think there is a need for IANA to track the bit allocations in the Flags field of the Message_ID List object? Section 7.2 You might want to consider removing this reference since the I-D is, I think, expired without any intention of being regenerated. Section 11 The year is now 2005 :-) Thanks, Adrian From owner-ccamp@ops.ietf.org Fri May 13 07:38:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06054 for ; Fri, 13 May 2005 07:38:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWYku-0002y9-Uf for ccamp-archive@ietf.org; Fri, 13 May 2005 07:55:02 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWYL8-000Jor-Ct for ccamp-data@psg.com; Fri, 13 May 2005 11:28:22 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWYL6-000JoZ-Fw for ccamp@ops.ietf.org; Fri, 13 May 2005 11:28:20 +0000 Received: from du-069-0258.access.clara.net ([217.158.145.4] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DWYL4-000Gor-8s for ccamp@ops.ietf.org; Fri, 13 May 2005 12:28:19 +0100 Message-ID: <002001c557af$276d3950$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <069301c54cba$10249c70$1c849ed9@Puppy> Subject: Last call complete on draft-ietf-ccamp-rsvp-restart-ext-02.txt Date: Fri, 13 May 2005 12:26:49 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Editors, Please update the draft with the last call comments and resubmit it. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri May 13 08:00:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07179 for ; Fri, 13 May 2005 08:00:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWZ6B-0003rN-GT for ccamp-archive@ietf.org; Fri, 13 May 2005 08:16:59 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWYfq-000L37-No for ccamp-data@psg.com; Fri, 13 May 2005 11:49:46 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWYfo-000L2u-Sp for ccamp@ops.ietf.org; Fri, 13 May 2005 11:49:45 +0000 Received: from du-069-0258.access.clara.net ([217.158.145.4] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DWYfn-000NGL-8E; Fri, 13 May 2005 12:49:44 +0100 Message-ID: <003f01c557b2$25417850$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Incoming liaison from ITU-T SG13 on L1VPNs Date: Fri, 13 May 2005 12:51:26 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hi, I have just received the following liaison from ITU-T Study Group 13. The pdf version of the liaison can be found at incoming liaisons page of the alternate CCAMP web site. http://www.olddog.co.uk/ccamp.htm The liaison will find its way onto the IETF's liaison pages when the Secretariat have processed it. Since the liaison is for action, we can expect to respond with a statement of our progress on L1VPNs. Cheers, Adrian ======= From: Marco Carugi, Rapporteur of ITU-T SG13 Question 2 To: IETF Routing Area CCAMP Working Group Subject: L1VPN related work collaboration For: Action Deadline: 29th August 2005 SG 13 would like to thank the IETF CCAMP WG for your liaison replies in the area of L1VPNs, informing us about your recent progress on this subject, as well as the new mailing list creation. Thank you for your review of the ITU-T documents on service level requirements and framework for L1VPNs, now published as Y.1312 (Layer 1 Virtual Private Network Generic Requirements and Architecture Elements) and Y.1313 (Layer 1 Virtual Private Network service and network architectures). We are aware that these service level requirements and framework have been summarized in the Internet-Draft draft-takeda-l1vpn-framework, and that work is ongoing in the IETF community to assess the suitability of existing IETF protocols to meet the requirements within the context of the framework. We appreciate and would definitely like to continue our collaboration with the IETF on this subject so that, following the analysis of the suitability of the existing IETF protocols for L1VPN service delivery, any necessary protocol extensions are appropriately accomplished within the IETF. Please continue to keep us informed about your progress in the area of L1VPNs. Our next meeting is planned for August 25 - September 9 2005 in Geneva. From owner-ccamp@ops.ietf.org Fri May 13 13:29:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07730 for ; Fri, 13 May 2005 13:29:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWeEO-0000Ss-78 for ccamp-archive@ietf.org; Fri, 13 May 2005 13:45:51 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWdlp-000KC7-Ml for ccamp-data@psg.com; Fri, 13 May 2005 17:16:17 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWdlo-000KBl-To; Fri, 13 May 2005 17:16:17 +0000 Received: from du-069-0081.access.clara.net ([217.158.132.81] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DWdln-000Nge-6h; Fri, 13 May 2005 18:16:16 +0100 Message-ID: <013601c557df$c3042740$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "JP Vasseur" Cc: , "Scott Bradner" , , "Bill Fenner" References: <006201c53b95$855fa150$6fcb2bd4@Puppy> Subject: Re: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Fri, 13 May 2005 18:18: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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit JP, Thanks for your proposals. After consultation, I find that under the new IPR rules we do not make specific reference to IPR disclosures in I-Ds or RFCs. Instead, the boilerplate says that there "may be" IPR claims, and refers the reader to the Web pages. This is a future-proof technique. Therefore, I have tweaked your suggestions below. > 1. Text is added to the I-D as follows. > > The procedures described in this document are the subject of an > Intellectual Property Rights claim. For this reason, the procedures are > entirely optional within an MPLS or GMPLS network. Implementations that > do not support the procedures described in this document will > interoperate seamlessly with those that do. > Further, an implementation that does not support the procedures > described in this document will not be impacted or implicated by a > neighboring implementation that does implement the procedures. Replace this paragraph with... The procedures described in this document are entirely optional within an MPLS or GMPLS network. Implementations that do not support the procedures described in this document will interoperate seamlessly with those that do. Further, an implementation that does not support the procedures described in this document will not be impacted or implicated by a neighboring implementation that does implement the procedures. > An ingress implementation that chooses not to support the procedures > described in this document may still achieve re-optimization by > periodically issuing a speculative make-before-break replacement of an > LSP without trying to discovery whether a more optimal path is > available in a downstream domain. Such a procedure would not be in > conflict with any mechanisms not already documented in [RFC3209] and > [RFC3473]. Second paragraph is fine. > 2. The I-D should be updated with comments arising from the WG last > call. Yes please. > 3. The I-D should be progressed as an informational RFC Yes. This is advisable. Please update the I-D and submit it. I will then forward it to Alex for AD review. Cheers, Adrian From owner-ccamp@ops.ietf.org Sat May 14 11:17:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10484 for ; Sat, 14 May 2005 11:17:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWyeH-0002ua-2K for ccamp-archive@ietf.org; Sat, 14 May 2005 11:33:53 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWyFM-000Gdi-03 for ccamp-data@psg.com; Sat, 14 May 2005 15:08:08 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWyFK-000GdN-5b for ccamp@ops.ietf.org; Sat, 14 May 2005 15:08:06 +0000 Received: from du-069-0210.access.clara.net ([217.158.132.210] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DWyFI-000J10-Gi; Sat, 14 May 2005 16:08:04 +0100 Message-ID: <019301c55897$051d7610$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> Subject: Re: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt Date: Sat, 14 May 2005 15:50:25 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Hi Tom, Thanks for your comments which we are (finally) addressing. > I find the IANA Considerations section less than clear. I suggest that you > differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB OK. > I would also reword it slightly as follows. > > ** MPLS and GMPLS related standards track MIB modules are rooted under the > mplsStdMIB subtree. > > One of the MIB modules contained in this document extends tables > contained in MPLS MIB modules. OK > ** The two MIB modules contained in this document, like that in > GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree. OK > ** New assignments in the mplsStdMIB subtree can only be made via a Standards > Action as specified in [RFC2434]. OK > 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB > > ** The IANA is requested to assign { mplsStdMIB yy } to the > GMPLS-LABEL-STD-MIB module specified in this document. Yes, as above. Thanks, Adrian and Tom (Your other emails on these MIBs will be responded to separately.) From owner-ccamp@ops.ietf.org Sat May 14 11:19:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10602 for ; Sat, 14 May 2005 11:19:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWygD-00030K-3a for ccamp-archive@ietf.org; Sat, 14 May 2005 11:35:53 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWyFX-000GfB-Rb for ccamp-data@psg.com; Sat, 14 May 2005 15:08:19 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWyFW-000Get-6l for ccamp@ops.ietf.org; Sat, 14 May 2005 15:08:18 +0000 Received: from du-069-0210.access.clara.net ([217.158.132.210] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DWyFU-000J10-J6; Sat, 14 May 2005 16:08:17 +0100 Message-ID: <019401c55897$0cb52030$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Sat, 14 May 2005 15:57:20 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi Tom, Next in the series of your comments on the GMPLS MIBs. > A minor comment; this document has > false (0), > in several places; following RFC 2579, I think this should be > false (2) OK > A larger question,; this mib augments tables in the mpls mib (RFC3812); is there > a reason why the AUGMENTS construct was not used? You and I discussed this on the list a bit. I think we came to the conclusion that: - Augments is what we intended - it fits the usage - the indexing is needed because the new table is a separate table. So, no action, but I expect the MIB Doctors (TM) will pick up on it if there are any issues. Cheers, Adrian From owner-ccamp@ops.ietf.org Sat May 14 14:53:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25656 for ; Sat, 14 May 2005 14:53:31 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX21h-0002Rd-5O for ccamp-archive@ietf.org; Sat, 14 May 2005 15:10:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DX1d9-0004z4-GG for ccamp-data@psg.com; Sat, 14 May 2005 18:44:55 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DX1d7-0004yp-M9 for ccamp@ops.ietf.org; Sat, 14 May 2005 18:44:53 +0000 Received: from du-069-0037.access.clara.net ([217.158.132.37] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DX1d5-000KYN-IJ; Sat, 14 May 2005 19:44:52 +0100 Message-ID: <01a101c558b5$4e61e310$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" Cc: References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> <000e01c52b94$e310a440$0601a8c0@pc6> Subject: Re: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Sat, 14 May 2005 17:26:08 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Hi Tom, This is a very good point. We have been struggling with this for a while (I believe that Bert gave me a pointer, but I don't think I understood the issue properly before). Thanks to your explanation and the new text in the MIB guideline, we have taken care of the issue. Cheers, Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Friday, March 18, 2005 9:29 AM Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt > This MIB contains several 'enumerations' except they are not enumerations but > text in > DESCRIPTION clauses - gmplsTunnelGPid gmplsTunnelSwitchingType > gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference. So these are > not defined anywhere in SMI; and as this points out, these values will be added > to in future RFC. > > I think these should be in a MIB under IANA control and there is already a way > to do just that, namely to put them in an IANA MIB (as opposed to a standards > track MIB) with the RFC specifying under what conditions the IANA MIB can be > updated (standards track, IESG, expert etc). > > This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which > also points to previous examples of this. And this issue has already surfaced, > albeit obliquely, on this list once before in the context of > IANAItuProbableCause which uses this procedure and is now published as part of > the Alarm MIB (RFC 3877). > > Not to do this now creates extra work in the future; when an implementor has to > create their own SMI and whenever these values need to be updated. > > Tom Petch > > > From owner-ccamp@ops.ietf.org Sat May 14 17:38:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06042 for ; Sat, 14 May 2005 17:38:47 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX4be-0008Fw-OX for ccamp-archive@ietf.org; Sat, 14 May 2005 17:55:36 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DX4Cq-000FZQ-1p for ccamp-data@psg.com; Sat, 14 May 2005 21:29:56 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DX4Cp-000FZ0-0g; Sat, 14 May 2005 21:29:55 +0000 Received: from du-069-0189.access.clara.net ([217.158.132.189] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DX4Ck-000M8r-JJ; Sat, 14 May 2005 22:29:51 +0100 Message-ID: <01c101c558cc$5b0034c0$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Bill Fenner" , "WG Milestone Tracker" Subject: draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt ready for AD review Date: Sat, 14 May 2005 20:06:08 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Hi Alex, draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt is ready for AD review with a view to moving it along to IETF last call and IESG review. The draft has: - been reviewed by me as CCAMP chair - been through CCAMP WG last call - been updated from these steps to my satisfaction. The I-D is targeted at the Standards Track. Thanks, Adrian From owner-ccamp@ops.ietf.org Mon May 16 08:46:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06278 for ; Mon, 16 May 2005 08:46:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXfFa-0002kz-Vs for ccamp-archive@ietf.org; Mon, 16 May 2005 09:03:15 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DXemW-000MVy-MG for ccamp-data@psg.com; Mon, 16 May 2005 12:33:12 +0000 Received: from [80.168.70.150] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DXemT-000MVY-RE; Mon, 16 May 2005 12:33:10 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DXemS-000JEW-IE; Mon, 16 May 2005 13:33:08 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk, zinin@psg.com, kireeti@juniper.net Reply-To: adrian@olddog.co.uk Subject: Proposal to kill Tunnel Trace Date: Mon, 16 May 2005 13:33:08 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.7 Message-Id: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi, Notwithstanding the reasonably mature state of draft-ietf-ccamp-tunproto-01 there appears to be zero support in the community to complete the work, and more importantly to implement it. So, although we have a requirements RFC and a charter action for this work, I am proposing that we kill this I-D (or at least let it expire peacefully). We have discussed this amongst the authors and ADs and have agreement, but I need to offer you the opportunity to comment against (or for) this proposal. Be aware that if you are in favor of keeping this work alive, you will need to commit to work on the draft, and also to implement it. We can assume that if/when people start to implement and deploy hierarchical LSPs in earnest they may come back and resurrect the I-D. If any of you objects to this (for example, you know of imminent plans to implement, or deployments that will really need this work), then please speak up now. Thanks, Adrian From info@mail.sibou3.com Mon May 16 20:38:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20567 for ; Mon, 16 May 2005 20:38:33 -0400 (EDT) Received: from [211.240.66.26] (helo=mail.sibou3.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DXqN8-0007AS-OZ for ccamp-archive@ietf.org; Mon, 16 May 2005 20:55:48 -0400 Received: (qmail 7114 invoked by uid 509); 16 May 2005 14:35:40 +0900 Date: 16 May 2005 14:35:40 +0900 Message-ID: <20050516053540.7112.qmail@mail.sibou3.com> From: info@sibou3.com To: ccamp-archive@ietf.org Subject: 新規登録の方は10000円分無料 X-Spam-Score: 4.6 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 一万円分！完全無料で使用OK ■今なら間に合うWチャンス！無料ポイントアップ楽しさ100倍！■ ※登録女性会員のジャンル別人気ランキング 一位：逆援（189名登録） 二位：援交（429名登録） 三位：SM逆援（243名登録） 四位：セフレ（1038名登録） 五位：不倫（2421名登録） 六位：テレエッチ（3463名登録） ・ ・ ・ 一万円分完全無料でお試しは ↓↓↓ http://awg.webchu.com/?summer23 只今！新規登録した方には無料で10,000円分ご利用出来ます。 【無料ポイント内で十分にパートナーを探す事が出来ます。】 ※18歳以上の秘密厳守できる方なら何方でも利用OK ↓↓入口↓↓ CLICK http://awg.webchu.com/?summer23 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ※18歳未満のご利用遠慮下さい。 今後、メールの受信を拒否する場合は下記URLに返信下さい。 henshin_senyou@ok.kz From owner-ccamp@ops.ietf.org Tue May 17 06:27:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03831 for ; Tue, 17 May 2005 06:27:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXzZH-0004qj-TR for ccamp-archive@ietf.org; Tue, 17 May 2005 06:44:56 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DXz82-0004B7-0s for ccamp-data@psg.com; Tue, 17 May 2005 10:16:46 +0000 Received: from [80.168.70.150] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DXz81-0004Au-76 for ccamp@ops.ietf.org; Tue, 17 May 2005 10:16:45 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DXz7z-000GmT-8A; Tue, 17 May 2005 11:16:43 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: leil@buptnet.edu.cn, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Questions on draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Date: Tue, 17 May 2005 11:16:43 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.25 Message-Id: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Hi, Posting this question on behalf of Lei Lei who has had some difficulty subscribing to the list. Thanks, Adrian === The section 8.4.1 of draft-ietf-ccamp-gmpls-recovery-analysis-05.txt discusses how to realize recovery resource sharing using GMPLS protocols. It draws the conclusion that no further extensions of GMPLS routing protocols are needed to perform this task, since the use of Maximum Reservable Bandiwidth, the Unreserved Bandwidth and the Maximum LSP Bandwidth is sufficient for the purpose. However, I do not quite follow this idea. I've read the [KODIALAM1], [KODIALAM2] and [GLI] papers, which is referred to in the draft, even before I read this draft. I have no problem in understanding the ideas described in those papers, In those papers, the Maximum TE Link Bandwidth is divided into three parts: the capacity committed for working LSPs, and capacity reserved for backup LSPs, and the unallocated capacity. The Partial Information routing algorithm needs to know the above three values in order to compute the optimal path. The Full Information routing algorithm in [GLI] needs still more information. However, section 8.4.1 of draft-ietf-ccamp-gmpls-recovery-analysis-05.txt claims that only the value of Maximum Reservable Bandiwidth, the Unreserved Bandwidth and the Maximum LSP Bandwidth need to be avaiable for recovery resource sharing, as shown in the figure below. But I do not understand how. 1. I do not understand the relationships between the Max Reservable Bandwidth, Maximum LSP Bandwidth and the Unreserved Bandwidth. 1.a Why should the difference between Max Reservable Bandwidth and the Maximum LSP Bandwidth be the Maximum Shareable Bandwidth? 1.b Why should the difference between the Max Reservable Bandwidth and the Maximum TE Link Bandwidth be the amount of bandwidth currently allocated for shared recovery? The Max Reservable Bandwidth should be larger than the Maximum TE Link Bandwidth, then how to set the exact value of Max Reservable Bandwidth? Is it decided by policy or can be calculated by some equations? Is it a constant value during network operation or change over time? 1.c Why should the difference between the Maximum TE Link Bandwidth and the Maximum LSP Bandwidth be the actual bandwidth committed for shared recovery instead of the sum of the bandwidth committed for working LSPs and the actual bandwidth committed for shared recovery? 2. What is the routing algorithm supposed to be used in this method? I suppose the working LSP can be calculated with SPF algorithm on the network topology where the links whose Maximum LSP Bandwidth smaller than the request bandwidth are pruned? But how to calculate the optimum backup path? Is it similar with the Partial Information approach? If it is, I fail to see how this could be done. - ---------- Max Reservable Bandwidth | ----- ^ |R ----- | | ----- | - ----- |max_R ----- | -------- TE link Capacity - ------ | - Maximum TE Link Bandwidth ----- |r ----- v ----- <------ b ------> - ---------- Maximum LSP Bandwidth ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- <--- Minimum LSP Bandwidth -------- 0 ---------- 0 Best regards Lei Lei From owner-ccamp@ops.ietf.org Tue May 17 15:38:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00982 for ; Tue, 17 May 2005 15:38:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8Ac-0002S8-LT for ccamp-archive@ietf.org; Tue, 17 May 2005 15:56:03 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DY7hl-000H0V-2g for ccamp-data@psg.com; Tue, 17 May 2005 19:26:13 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DY7hi-000H0A-KX; Tue, 17 May 2005 19:26:11 +0000 Message-ID: <428A454F.7030705@psg.com> Date: Tue, 17 May 2005 21:26:07 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, leil@buptnet.edu.cn, adrian@olddog.co.uk Subject: Re: Questions on draft-ietf-ccamp-gmpls-recovery-analysis-05.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit adrian, see below Adrian Farrel wrote: > Hi, > Posting this question on behalf of Lei Lei who has had some difficulty > subscribing to the list. > Thanks, > Adrian > === > The section 8.4.1 of draft-ietf-ccamp-gmpls-recovery-analysis-05.txt > discusses how to realize recovery resource sharing using GMPLS protocols. > It draws the conclusion that no further extensions of GMPLS routing > protocols are needed to perform this task, since the use of Maximum > Reservable Bandiwidth, the Unreserved Bandwidth and the Maximum LSP > Bandwidth is sufficient for the purpose. However, I do not quite follow > this idea. > I've read the [KODIALAM1], [KODIALAM2] and [GLI] papers, which is > referred to in the draft, even before I read this draft. I have no > problem in understanding the ideas described in those papers, In those > papers, the Maximum TE Link Bandwidth is divided into three parts: the > capacity committed for working LSPs, and capacity reserved for backup > LSPs, and the unallocated capacity. The Partial Information routing > algorithm needs to know the above three values in order to compute the > optimal path. The Full Information routing algorithm in [GLI] needs > still more information. However, section 8.4.1 of > draft-ietf-ccamp-gmpls-recovery-analysis-05.txt > claims that only the value of Maximum Reservable Bandiwidth, the > Unreserved Bandwidth and the Maximum LSP Bandwidth need to be avaiable > for recovery resource sharing, as shown in the figure below. But I do > not understand how. > 1. I do not understand the relationships between the Max Reservable > Bandwidth, Maximum LSP Bandwidth and the Unreserved Bandwidth. the relationships have been defined in various GMPLS routing documents, the profile proposed is by definition informational and shows a way to use these parameters such as to obtain the stated objective all the below questions are specific to local policy rules and subject to initial configuration (except the nominal link capacity which is determined by the interface capability) > 1.a Why should the difference between Max Reservable Bandwidth and the > Maximum LSP Bandwidth be the Maximum Shareable Bandwidth? > 1.b Why should the difference between the Max Reservable Bandwidth and > the Maximum TE Link Bandwidth be the amount of bandwidth currently > allocated for shared recovery? > The Max Reservable Bandwidth should be larger than the Maximum TE > Link Bandwidth, then how to set the exact value of Max Reservable > Bandwidth? > Is it decided by policy or can be calculated by some equations? > Is it a constant value during network operation or change over time? > 1.c Why should the difference between the Maximum TE Link Bandwidth and > the Maximum LSP Bandwidth be the actual bandwidth committed for > shared recovery instead of the sum of the bandwidth committed for > working LSPs and the actual bandwidth committed for shared recovery? > 2. What is the routing algorithm supposed to be used in this method? > I suppose the working LSP can be calculated with SPF algorithm on the > network topology where the links whose Maximum LSP Bandwidth smaller > than the request bandwidth are pruned? But how to calculate the optimum > backup path? Is it similar with the Partial Information approach? If it > is, I fail to see how this could be done. additional information needed for the partial information model is to find a way to determine the (shared) bandwidth reserved on each link by protecting LSPs that have already been set up (soft-provisioning) - so instead here of requiring such additional information, the setup discussed in this section is proposing to maximize the ratio between over-provisioned bandwidth and actual bandwidth that can be committed by assuming over-provisioning is used for shared recovery purposes; the considerations do not detail the exact algorithm but assess that the available information is enough achieve this computation > - ---------- Max Reservable Bandwidth > | ----- ^ > |R ----- | > | ----- | > - ----- |max_R > ----- | > -------- TE link Capacity - ------ | - Maximum TE Link Bandwidth > ----- |r ----- v > ----- <------ b ------> - ---------- Maximum LSP Bandwidth > ----- ----- > ----- ----- > ----- ----- > ----- ----- > ----- ----- <--- Minimum LSP Bandwidth > -------- 0 ---------- 0 > > Best regards > Lei Lei > > > . > From owner-ccamp@ops.ietf.org Wed May 18 09:34:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19891 for ; Wed, 18 May 2005 09:34:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYOxV-0006bD-SS for ccamp-archive@ietf.org; Wed, 18 May 2005 09:51:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYOVx-0008PW-1v for ccamp-data@psg.com; Wed, 18 May 2005 13:23:09 +0000 Received: from [202.205.253.249] (helo=sammy.buptnet.edu.cn) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DYOVs-0008P9-P6 for ccamp@ops.ietf.org; Wed, 18 May 2005 13:23:05 +0000 Received: (qmail 31290 invoked by uid 89); 18 May 2005 13:23:01 -0000 Received: by simscan 1.1.0 ppid: 31282, pid: 31285, t: 0.7466s scanners: attach: 1.1.0 clamav: 0.83/m:30/d:848 spam: 3.0.2 Received: from unknown (HELO kan) (leil@59.64.148.120) by 0 with SMTP; 18 May 2005 13:23:00 -0000 Message-ID: <000a01c55bac$c462a9b0$1700a8c0@kan> From: "Lei Lei" To: Cc: , "Leilei" Subject: Re:questions on draft-ietf-ccamp-gmpls-recovery-analysis-05 Date: Wed, 18 May 2005 21:23:23 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C55BEF.D26A7270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE,MIME_BASE64_TEXT,SUBJ_HAS_UNIQ_ID autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.4 (++) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C55BEF.D26A7270 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQogICAgRmlyc3Qgb2YgYWxsLCBJIHdvdWxkIGxpa2UgdG8gdGhhbmsgTXIgRmFycmVsIGZvciBr aW5kbHkgb2ZmZXJpbmcgbWUgc3VjaCBhIGdyZWF0IGhlbHAgYW5kIE1yICBQYXBhZGltaXRyaW91 IGZvciB0YWtpbmcgdGhlIHRpbWUgYW5kIHRyb3VibGUgdG8gYW5zd2VyIG15IHF1ZXN0aW9ucy4g SG93ZXZlciwgSSBzdGlsbCBoYXZlIHNvbWUgZGlmZmljdWx0eSBpbiB1bmRlcnN0YW5kaW5nIHRo ZSBpZGVhIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDguNC4xIG9mIGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtcmVjb3ZlcnktYW5hbHlzaXMtMDUuIEknbSBzb3JyeSBmb3IgYm90aGVyaW5nIHlvdSB3aXRo IG15IHF1ZXN0aW9ucyxidXQgbmVpdGhlciBtZSBub3IgbXkgY29sbGVhZ3VlcyBjYW4gY2xlYXIg dGhpcyBjb25mdXNpb24uICAgIA0KDQogICBGcm9tIHRoZSBsYXN0IGVtYWlsLCBJIHVuZGVyc3Rh bmQgdGhhdCB0aGUgZXNzZW5jZSBvZiB0aGUgaWRlYSBpcyB0byBtYXhpbWl6ZSB0aGUgcmF0aW8g YmV0d2VlbiBvdmVyLXByb3Zpc2lvbmVkIGJhbmR3aWR0aCBhbmQgYWN0dWFsIGJhbmR3aWR0aCB0 aGF0IGNhbiBiZSBjb21taXR0ZWQgYnkgYXNzdW1pbmcgb3Zlci1wcm92aXNpb25pbmcgaXMgdXNl ZCBmb3Igc2hhcmVkIHJlY292ZXJ5IHB1cnBvc2VzLiBNeSBxdWVzdGlvbnMgYXJlIGFzIGZvbGxv d3M6DQoNCjEuIFRoZSBjb25jZXB0IG9mIG92ZXItc3Vic2NyaXB0aW9uIGluIHJlY292ZXJ5IHJl c291cmNlIHNoYXJpbmcuIENhbiBJIGRlc2NyaWJlIHRoZSBvdmVyLXByb3Zpc2lvbmVkIGJhbmR3 aWR0aCBhcyB0aGUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgcmVjb3ZlcnkgYmFuZHdpZHRo IHRoYXQgc2hvdWxkIGJlIGFsbG9jYXRlZCBpZiBhIGRlZGljYXRlZCBwcm90ZWN0aW9uIHNjaGVt ZSBpcyBhc3N1bWVkIGFuZCB0aGUgcmVjb3ZlcnkgYmFuZHdpZHRoIHRoYXQgaXMgYWN0dWFsbHkg IHJlc2VydmVkIGNvbnNpZGVyaW5nIHJlY292ZXJ5IHJlc291cmNlIHNoYXJpbmc/IFRoYXQgaXMs IHRoZSBhbW91dCBvZiBiYW5kd2lkdGggIHRoYXQgaXMgc2F2ZWQgYnkgcmVjb3ZlcnkgcmVzb3Vy Y2Ugc2hhcmluZz8NCg0KMi4gVGhlIG1lYW5pbmcgb2YgUltpXS4gSW4gdGhlIGRyYWZ0LCBpdCBp cyBzYWlkIHRoYXQgUltpXSBpcyB0aGUgYW1vdW50IG9mIGJhbmR3aWR0aCBjdXJyZW50bHkgYWxs b2NhdGVkIGZvciBzaGFyZWQgcmVjb3ZlcnkgIGFuZCByW2ldIGlzIHRoZSBhY3R1YWwgYmFuZHdp ZHRoIGNvbW1pdHRlZCBmb3Igc2hhcmVkIHJlY292ZXJ5LiBIb3dldmVyLCB0aGlzIGRlZmluaXRp b24gb2YgUltpXSBpcyBub3QgY2xlYXIgZW5vdWdoIGZvciBtZS4gQ2FuIEkgdW5kZXJzdGFuZCBy W2ldIGFzIHRoZSByZWNvdmVyeSBiYW5kd2lkdGggYWN0dWFsbHkgcmVzZXJ2ZWQgb24gdGhlIGxp bmssIGFuZCBSW2ldIGFzIHRoZSBiYW5kd2lkdGggdGhhdCBzaG91bGQgYmUgYWxsb2NhdGVkIGlm IGEgZGVkaWNhdGVkIHByb3RlY3Rpb24gc2NoZW1lIGlzIGFzc3VtZWQ/IFNvIFJbaV0gLSByW2ld IGlzIHRoZSBhbW91bnQgb2YgYmFuZHdpZHRoIGN1cnJlbnRseSBzYXZlZCBieSByZWNvdmVyeSBy ZXNvdXJjZSBzaGFyaW5nPyBBbHNvLGluIHRoZSBmaWd1cmUgYmVsb3csIGRvZXMgcltpXSBtZWFu IHRoZSBiYW5kd2lkdGggZnJvbSBwb2ludCAxIHRvIHBvaW50IDMgb3IgZnJvbSBwb2ludCAyIHRv IHBvaW50IDQ/IERvZXMgUltpXSBtZWFucyB0aGUgYmFuZHdpZHRoIGZyb20gcG9pbnQgMSB0byBw b2ludCA2IG9yIGZyb20gcG9pbnQgNSB0byBwb2ludCA3Pw0KDQozLiBGcm9tIHRoZSBmaWd1cmUg YmVsb3cgaXQgc2VlbXMgdGhhdCBiW2ldIGVxdWFscyB0byBNYXhpbXVtIExTUCBCYW5kd2lkdGgs IGlzIGl0IHRydWU/IGJbaV0gaXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQgYXMgdGhlIHN1bSBwZXIg VEUgbGluayBpIG9mIHRoZSBiYW5kd2lkdGggY29tbWl0dGVkIGZvciB3b3JraW5nIExTUHMgYW5k IG90aGVyIHJlY292ZXJ5IExTUHMgKHRodXMgZXhjZXB0ICJzaGFyZWQgYmFuZHdpZHRoIiBMU1Bz KS4gSXQgc2VlbXMgdGhhdCBiW2ldIGlzIHRoZSBhbW91bnQgb2YgYWxsb2NhdGVkIGJhbmR3aWR0 aCB0aGF0IGNhbm5vdCBiZSBzaGFyZWQgd2l0aCBjdXJyZW50IExTUC4gVGh1cywgaXQgaXMgc3Ry YW5nZSB0aGF0IGJbaV0gc2hvdWxkIGJlIGVxdWFscyB0byBNYXhpbXVtIExTUCBCYW5kd2lkdGgs IHdoaWNoIGVxdWFscyB0byB0aGUgVW5yZXNlcnZlZCBCYW5kd2lkdGguIEJ1dCBvdGhlcndpc2Us IHdoYXQgZG9lcyB0aGUgPC0tLS0tLSBiIC0tLS0tLT4gaW4gdGhlIGZpZ3VyZSBiZWxvdyBtZWFu Pw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3IC0g LS0tLS0tLS0tLSBNYXggUmVzZXJ2YWJsZSBCYW5kd2lkdGggDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIC0tLS0tICBeICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYgIHxSIC0tLS0tfCAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNSAgfCAgLS0tLS0gIHwg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSAtLS0t LSAgICB8bWF4X1IgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLS0tLSAgICB8IA0KICAgLS0tLS0tLS0gIFRFIGxpbmsgQ2FwYWNpdHkgICAgICAg ICAgICAgICA0IC0gLS0tLS0tIHwgLSBNYXhpbXVtIFRFIExpbmsgQmFuZHdpZHRoIA0KICAgLS0t LS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzIHxyIC0tLS0tICB2IA0KICAg LS0tLS0gICAgIDwtLS0tLS0gYiAtLS0tLS0+ICAgICAgICAgICAgICAyIC0gLS0tLS0tLS0tLSBN YXhpbXVtIExTUCBCYW5kd2lkdGggDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0tLS0gDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0tLS0gDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLS0tLSANCiAgIC0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLS0tLSAgDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0tLS0gPC0tLSBNaW5pbXVtIExTUCBCYW5kd2lkdGggDQogICAtLS0t LS0tLSAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIC0tLS0tLS0tLS0gMCAN Cg0KICBJIHN0aWxsIGhhdmUgc29tZSBvdGhlciBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoaXMgc2Vj dGlvbiwgYnV0IEkgdGhpbmsgdGhhdCBpZiBJIGNhbiBnZXQgdGhlIGFib3ZlIHR3byBxdWVzdGlv bnMgY2xlYXIsIHBlcmhhcHMgSSBjYW4gZmlndXJlIG91dCB0aGUgb3RoZXJzIGJ5IG15c2VsZi4g SSdsbCBiZSB3YXJtbHkgbG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcmVwbHlzLg0KDQpCZXN0IHJl Z2FyZHMNCg0KTGVpIExlaQ== ------=_NextPart_000_0007_01C55BEF.D26A7270 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjIxODAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmYgYmFja2dyb3VuZD0iIj48Rk9OVCBzaXplPTI+PC9GT05UPjxC Uj48Rk9OVCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgRmlyc3Qgb2YgYWxsLCBJIHdvdWxk IGxpa2UgdG8gdGhhbmsgTXIgRmFycmVsIGZvciANCmtpbmRseSBvZmZlcmluZyBtZSBzdWNoIGEg Z3JlYXQgaGVscCBhbmQgTXImbmJzcDsgUGFwYWRpbWl0cmlvdSBmb3IgdGFraW5nIHRoZSANCnRp bWUgYW5kIHRyb3VibGUgdG8gYW5zd2VyIG15IHF1ZXN0aW9ucy4gSG93ZXZlciwgSSBzdGlsbCBo YXZlIHNvbWUgZGlmZmljdWx0eSANCmluIHVuZGVyc3RhbmRpbmcgdGhlIGlkZWEgZGVzY3JpYmVk IGluIHNlY3Rpb24gOC40LjEgb2YgDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXJlY292ZXJ5LWFu YWx5c2lzLTA1LiBJJ20gc29ycnkgZm9yIGJvdGhlcmluZyB5b3Ugd2l0aCBteSANCnF1ZXN0aW9u cyxidXQgbmVpdGhlciBtZSBub3IgbXkgY29sbGVhZ3VlcyBjYW4gY2xlYXIgdGhpcyANCmNvbmZ1 c2lvbi4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPjxCUj4mbmJzcDsmbmJzcDsgRnJvbSB0aGUgbGFz dCBlbWFpbCwgSSANCnVuZGVyc3RhbmQgdGhhdCB0aGUgZXNzZW5jZSBvZiB0aGUgaWRlYSBpcyB0 byBtYXhpbWl6ZSB0aGUgcmF0aW8gYmV0d2VlbiANCm92ZXItcHJvdmlzaW9uZWQgYmFuZHdpZHRo IGFuZCBhY3R1YWwgYmFuZHdpZHRoIHRoYXQgY2FuIGJlIGNvbW1pdHRlZCBieSANCmFzc3VtaW5n IG92ZXItcHJvdmlzaW9uaW5nIGlzIHVzZWQgZm9yIHNoYXJlZCByZWNvdmVyeSBwdXJwb3Nlcy4g TXkgcXVlc3Rpb25zIA0KYXJlIGFzIGZvbGxvd3M6PEJSPjxCUj4xLiBUaGUgY29uY2VwdCBvZiBv dmVyLXN1YnNjcmlwdGlvbiBpbiByZWNvdmVyeSByZXNvdXJjZSANCnNoYXJpbmcuIENhbiBJIGRl c2NyaWJlIHRoZSBvdmVyLXByb3Zpc2lvbmVkIGJhbmR3aWR0aCBhcyB0aGUgdGhlIGRpZmZlcmVu Y2UgDQpiZXR3ZWVuIHRoZSByZWNvdmVyeSBiYW5kd2lkdGggdGhhdCBzaG91bGQgYmUgYWxsb2Nh dGVkIGlmIGEgZGVkaWNhdGVkIA0KcHJvdGVjdGlvbiBzY2hlbWUgaXMgYXNzdW1lZCBhbmQgdGhl IHJlY292ZXJ5IGJhbmR3aWR0aCB0aGF0IGlzIGFjdHVhbGx5Jm5ic3A7IA0KcmVzZXJ2ZWQgY29u c2lkZXJpbmcgcmVjb3ZlcnkgcmVzb3VyY2Ugc2hhcmluZz8gVGhhdCBpcywgdGhlIGFtb3V0IG9m IA0KYmFuZHdpZHRoJm5ic3A7IHRoYXQgaXMgc2F2ZWQgYnkgcmVjb3ZlcnkgcmVzb3VyY2Ugc2hh cmluZz88QlI+PEJSPjIuIFRoZSANCm1lYW5pbmcgb2YgUltpXS4gSW4gdGhlIGRyYWZ0LCBpdCBp cyBzYWlkIHRoYXQgUltpXSBpcyB0aGUgYW1vdW50IG9mIGJhbmR3aWR0aCANCmN1cnJlbnRseSBh bGxvY2F0ZWQgZm9yIHNoYXJlZCByZWNvdmVyeSZuYnNwOyBhbmQgcltpXSBpcyB0aGUgYWN0dWFs IGJhbmR3aWR0aCANCmNvbW1pdHRlZCBmb3Igc2hhcmVkIHJlY292ZXJ5LiBIb3dldmVyLCB0aGlz IGRlZmluaXRpb24gb2YgUltpXSBpcyBub3QgY2xlYXIgDQplbm91Z2ggZm9yIG1lLiBDYW4gSSB1 bmRlcnN0YW5kIHJbaV0gYXMgdGhlIHJlY292ZXJ5IGJhbmR3aWR0aCBhY3R1YWxseSByZXNlcnZl ZCANCm9uIHRoZSBsaW5rLCBhbmQgUltpXSBhcyB0aGUgYmFuZHdpZHRoIHRoYXQgc2hvdWxkIGJl IGFsbG9jYXRlZCBpZiBhIGRlZGljYXRlZCANCnByb3RlY3Rpb24gc2NoZW1lIGlzIGFzc3VtZWQ/ IFNvIFJbaV0gLSByW2ldIGlzIHRoZSBhbW91bnQgb2YgYmFuZHdpZHRoIA0KY3VycmVudGx5IHNh dmVkIGJ5IHJlY292ZXJ5IHJlc291cmNlIHNoYXJpbmc/IEFsc28saW4gdGhlIGZpZ3VyZSBiZWxv dywgZG9lcyANCnJbaV0gbWVhbiB0aGUgYmFuZHdpZHRoIGZyb20gcG9pbnQgMSB0byBwb2ludCAz IG9yIGZyb20gcG9pbnQgMiB0byBwb2ludCA0PyBEb2VzIA0KUltpXSBtZWFucyB0aGUgYmFuZHdp ZHRoIGZyb20gcG9pbnQgMSB0byBwb2ludCA2IG9yIGZyb20gcG9pbnQgNSB0byBwb2ludCANCjc/ PEJSPjxCUj4zLiBGcm9tIHRoZSBmaWd1cmUgYmVsb3cgaXQgc2VlbXMgdGhhdCBiW2ldIGVxdWFs cyB0byBNYXhpbXVtIExTUCANCkJhbmR3aWR0aCwgaXMgaXQgdHJ1ZT8gYltpXSBpcyBkZWZpbmVk IGluIHRoZSBkcmFmdCBhcyB0aGUgc3VtIHBlciBURSBsaW5rIGkgb2YgDQp0aGUgYmFuZHdpZHRo IGNvbW1pdHRlZCBmb3Igd29ya2luZyBMU1BzIGFuZCBvdGhlciByZWNvdmVyeSBMU1BzICh0aHVz IGV4Y2VwdCANCiJzaGFyZWQgYmFuZHdpZHRoIiBMU1BzKS4gSXQgc2VlbXMgdGhhdCBiW2ldIGlz IHRoZSBhbW91bnQgb2YgYWxsb2NhdGVkIA0KYmFuZHdpZHRoIHRoYXQgY2Fubm90IGJlIHNoYXJl ZCB3aXRoIGN1cnJlbnQgTFNQLiBUaHVzLCBpdCBpcyBzdHJhbmdlIHRoYXQgYltpXSANCnNob3Vs ZCBiZSBlcXVhbHMgdG8gTWF4aW11bSBMU1AgQmFuZHdpZHRoLCB3aGljaCBlcXVhbHMgdG8gdGhl IFVucmVzZXJ2ZWQgDQpCYW5kd2lkdGguIEJ1dCBvdGhlcndpc2UsIHdoYXQgZG9lcyB0aGUgJmx0 Oy0tLS0tLSBiIC0tLS0tLSZndDsgaW4gdGhlIGZpZ3VyZSANCmJlbG93IA0KbWVhbj88QlI+PEJS PjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo3IC0gLS0t LS0tLS0tLSBNYXggUmVzZXJ2YWJsZSBCYW5kd2lkdGggDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNw OyAtLS0tLSZuYnNwOyBeJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjYmbmJzcDsgfFIgLS0tLS18Jm5ic3A7IA0KPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjUmbmJzcDsgfCZu YnNwOyAtLS0tLSZuYnNwOyB8IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0gLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsg fG1heF9SIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7IHwg PEJSPiZuYnNwOyZuYnNwOyAtLS0tLS0tLSZuYnNwOyBURSBsaW5rIA0KQ2FwYWNpdHkmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQombmJzcDs0IC0gLS0tLS0tIHwgLSBNYXhpbXVtIFRFIExpbmsgQmFu ZHdpZHRoIDxCUj4mbmJzcDsmbmJzcDsgDQotLS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCjMgfHIgLS0tLS0mbmJzcDsgdiA8QlI+Jm5ic3A7Jm5ic3A7IC0tLS0t Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0tLS0gYiANCi0tLS0tLSZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQoyIC0gLS0tLS0tLS0tLSBNYXhpbXVtIExTUCBCYW5kd2lkdGggPEJS PiZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0gPEJSPiZuYnNwOyZuYnNw OyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0gPEJSPiZuYnNwOyZuYnNwOyANCi0tLS0tJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KLS0tLS0gPEJSPiZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0m bmJzcDsgPEJSPiZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0gJmx0Oy0t LSBNaW5pbXVtIExTUCBCYW5kd2lkdGggPEJSPiZuYnNwOyZuYnNwOyAtLS0tLS0tLSANCjAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQombmJzcDsxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0gMCA8QlI+PEJSPiZu YnNwOyBJIHN0aWxsIGhhdmUgc29tZSANCm90aGVyIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhpcyBz ZWN0aW9uLCBidXQgSSB0aGluayB0aGF0IGlmIEkgY2FuIGdldCB0aGUgYWJvdmUgDQp0d28gcXVl c3Rpb25zIGNsZWFyLCBwZXJoYXBzIEkgY2FuIGZpZ3VyZSBvdXQgdGhlIG90aGVycyBieSBteXNl bGYuIEknbGwgYmUgDQp3YXJtbHkgbG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcmVwbHlzLjxCUj48 QlI+QmVzdCByZWdhcmRzPEJSPjxCUj5MZWkgDQpMZWk8L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0007_01C55BEF.D26A7270-- From owner-ccamp@ops.ietf.org Thu May 19 05:44:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10722 for ; Thu, 19 May 2005 05:44:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYhqn-0003SF-SS for ccamp-archive@ietf.org; Thu, 19 May 2005 06:02:00 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYhOV-000Dyv-C1 for ccamp-data@psg.com; Thu, 19 May 2005 09:32:43 +0000 Received: from [80.168.70.150] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYhOT-000Dyf-D7 for ccamp@ops.ietf.org; Thu, 19 May 2005 09:32:41 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DYhOS-000Iqh-60; Thu, 19 May 2005 10:32:40 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Incoming communication from OIF Date: Thu, 19 May 2005 10:32:39 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.50 Message-Id: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,DEAR_SOMETHING autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi, We have received a communication from the OIF. You can see it at http://www.olddog.co.uk/incoming.htm The text can be seen below. Note that there is no action required from us at this time, but if anyone believes there is any information we should send them. Adrian ========== To: Mr. Adrian Farrel, WG Co-Chair for IETF CCAMP Mr. Kireeti Kompella, WG Co-Chair for IETF CCAMP Dear Sirs, The OIF would like to inform you that at the 1Q2005 OIF Meeting, a new project was initiated to document the OIF requirements for Neighbor Discovery. The scope of this project is as follows: This project is targeted to identify the attribute information that must be exchanged in order to support the automatic initialization of the control plane when new links are discovered. Identifying the requirements will require: 1. Understanding Operational Scenarios where discovery will be used. While automatic initialization will reduce the operations intervention required to initialize new links, there may be cases where operators will not want discovery to automatically place links under the control of the Control Plane. Understanding the operational scenarios will allow for development of appropriate requirements. 2. Identify the attributes required by the Control Plane for initializing links. When discovery is allowed to place links into the Control Plane, the attribute information required by the Control Plane functions for the link must be identified. Further, since the attributes of a link may change over time, it is necessary to identify what sort of change in attributes must be possible without requiring the link to be re-initialized. 3. Identify and recommend solutions to the security issues that come from the discovery process exchanging Control Plane attributes. We intend to keep the ITU and IETF informed about this project and welcome your future cooperation. Thank you, Jim Jones, OIF Technical Committee Chair cc: Trey Malpass, Jonathan Sadler From gadi@arrowhead-classics.com Mon May 23 15:00:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28316 for ; Mon, 23 May 2005 15:00:06 -0400 (EDT) Received: from cpe-24-242-223-229.houston.res.rr.com ([24.242.223.229]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DaIRo-0000Uu-2j for ccamp-archive@ietf.org; Mon, 23 May 2005 15:18:45 -0400 Message-ID: <698801c55fc8$3e4ada77$f7c0e76c@arrowhead-classics.com> From: "Kendra L. Brown" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?V2luZG93cyBYUCAtIDc1JSBPRkY=?= Date: Mon, 23 May 2005 18:51:05 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_93ACD162.EFFFACC2" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_93ACD162.EFFFACC2 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_B7A586BA.EC915BA0" ------=_NextPart_001_0001_B7A586BA.EC915BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the popular software possible for bottom prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://www.software-disks.com Regards, Kendra L. Brown _____________________________________________________ To change your mail details, go: http://www.software-disks.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_B7A586BA.EC915BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get all the popular software possible for bottom prices!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... Enter here:

http://www.software-disks.com

Regards,
Kendra L. Brown


_____________________________________________________
To change your mail details, go: http://www.software-disks.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_B7A586BA.EC915BA0-- ------=_NextPart_000_0000_93ACD162.EFFFACC2-- From owner-ccamp@ops.ietf.org Mon May 23 15:49:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04599 for ; Mon, 23 May 2005 15:49:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaJDi-0002fv-F1 for ccamp-archive@ietf.org; Mon, 23 May 2005 16:08:14 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaIlj-000NIn-1U for ccamp-data@psg.com; Mon, 23 May 2005 19:39:19 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaIli-000NIZ-9A for ccamp@ops.ietf.org; Mon, 23 May 2005 19:39:18 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02520; Mon, 23 May 2005 15:39:16 -0400 (EDT) Message-Id: <200505231939.PAA02520@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt Date: Mon, 23 May 2005 15:39:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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 : A Framework for Inter-Domain MPLS Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-inter-domain-framework-02.txt Pages : 19 Date : 2005-5-23 This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-23144815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-23144815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue May 24 15:53:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08731 for ; Tue, 24 May 2005 15:53:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dafks-0002l6-B0 for ccamp-archive@ietf.org; Tue, 24 May 2005 16:11:58 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DafGf-0002pW-D0 for ccamp-data@psg.com; Tue, 24 May 2005 19:40:45 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DafGe-0002pI-L3 for ccamp@ops.ietf.org; Tue, 24 May 2005 19:40:44 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05820; Tue, 24 May 2005 15:40:41 -0400 (EDT) Message-Id: <200505241940.PAA05820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-crankback-05.txt Date: Tue, 24 May 2005 15:40:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --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 : Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-crankback-05.txt Pages : 33 Date : 2005-5-24 In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-crankback-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-crankback-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-24154849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-crankback-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-crankback-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-24154849.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue May 24 16:56:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23775 for ; Tue, 24 May 2005 16:56:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dagjm-0000Cb-TF for ccamp-archive@ietf.org; Tue, 24 May 2005 17:14:56 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DagLG-0008KE-D6 for ccamp-data@psg.com; Tue, 24 May 2005 20:49:34 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DagLF-0008K1-Jb for ccamp@ops.ietf.org; Tue, 24 May 2005 20:49:33 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j4OKnX978597 for ; Tue, 24 May 2005 13:49:33 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j4OKnSe04185 for ; Tue, 24 May 2005 13:49:28 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j4OKnR7v094276 for ; Tue, 24 May 2005 13:49:27 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j4OKnRjO094273 for ; Tue, 24 May 2005 13:49:27 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 24 May 2005 13:49:27 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Message-ID: <20050524134652.P88814@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20050524134652.N88814@kummer.juniper.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi All, This starts a two week CCAMP WG Last call on: draft-ietf-ccamp-inter-domain-framework-02.txt Please send your comments to the list (preferably) or to the authors latest by June 7, 23:59 GMT. Thanks, Kireeti. ------- ---------- Forwarded message ---------- Date: Mon, 23 May 2005 15:39:15 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Framework for Inter-Domain MPLS Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-inter-domain-framework-02.txt Pages : 19 Date : 2005-5-23 From owner-ccamp@ops.ietf.org Wed May 25 03:17:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13924 for ; Wed, 25 May 2005 03:17:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaqQz-00041j-O0 for ccamp-archive@ietf.org; Wed, 25 May 2005 03:36:11 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DapvV-000NJD-99 for ccamp-data@psg.com; Wed, 25 May 2005 07:03:37 +0000 Received: from [80.168.70.150] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DapvR-000NId-2i; Wed, 25 May 2005 07:03:35 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DapvO-0002lQ-7V; Wed, 25 May 2005 08:03:30 +0100 From: "Adrian Farrel" To: zinin@psg.com Cc: ccamp@ops.ietf.org, iesg-secretary@ietf.org, fenner@research.att.com, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: draft-ietf-ccamp-crankback-05.txt ready for AD review Date: Wed, 25 May 2005 08:03:30 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.28 Message-Id: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi Alex, draft-ietf-ccamp-crankback-05.txt is ready for AD review and progression through the process. It is targeted at Standards Track. The I-D has been through WG last call and has been liaised to ITU-T SG15. Updates have been made in response to comments made in both forums. I am happy with these updates, but note that I am also the editor of this document. Cheers, Adrian From owner-ccamp@ops.ietf.org Wed May 25 12:41:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27521 for ; Wed, 25 May 2005 12:41:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DazF6-0002N9-5X for ccamp-archive@ietf.org; Wed, 25 May 2005 13:00:30 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dayll-0009qN-4Y for ccamp-data@psg.com; Wed, 25 May 2005 16:30:09 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Daylk-0009qB-Ek for ccamp@ops.ietf.org; Wed, 25 May 2005 16:30:08 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 12:29:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4PGTUlS023676; Wed, 25 May 2005 12:29:56 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 12:29:55 -0400 Received: from [192.168.1.101] ([10.86.240.137]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 12:29:54 -0400 In-Reply-To: <013601c557df$c3042740$04919ed9@Puppy> References: <006201c53b95$855fa150$6fcb2bd4@Puppy> <013601c557df$c3042740$04919ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <59d78304545051025d916c06317d0d2a@cisco.com> Content-Transfer-Encoding: 7bit Cc: , "Scott Bradner" , , "Bill Fenner" From: JP Vasseur Subject: Re: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Wed, 25 May 2005 12:30:08 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 25 May 2005 16:29:54.0386 (UTC) FILETIME=[FB6E9320:01C56146] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Hi Adrian, draft-ietf-ccamp-loose-path-reopt has been republished with the agreed changes. Thanks. JP. On May 13, 2005, at 1:18 PM, Adrian Farrel wrote: > JP, > > Thanks for your proposals. > > After consultation, I find that under the new IPR rules we do not make > specific reference to IPR disclosures in I-Ds or RFCs. Instead, the > boilerplate says that there "may be" IPR claims, and refers the reader > to > the Web pages. This is a future-proof technique. > > Therefore, I have tweaked your suggestions below. > >> 1. Text is added to the I-D as follows. >> >> The procedures described in this document are the subject of an >> Intellectual Property Rights claim. For this reason, the procedures >> are >> entirely optional within an MPLS or GMPLS network. Implementations >> that >> do not support the procedures described in this document will >> interoperate seamlessly with those that do. >> Further, an implementation that does not support the procedures >> described in this document will not be impacted or implicated by a >> neighboring implementation that does implement the procedures. > > Replace this paragraph with... > The procedures described in this document are > entirely optional within an MPLS or GMPLS network. Implementations that > do not support the procedures described in this document will > interoperate seamlessly with those that do. > Further, an implementation that does not support the procedures > described in this document will not be impacted or implicated by a > neighboring implementation that does implement the procedures. > >> An ingress implementation that chooses not to support the procedures >> described in this document may still achieve re-optimization by >> periodically issuing a speculative make-before-break replacement of an >> LSP without trying to discovery whether a more optimal path is >> available in a downstream domain. Such a procedure would not be in >> conflict with any mechanisms not already documented in [RFC3209] and >> [RFC3473]. > > Second paragraph is fine. > >> 2. The I-D should be updated with comments arising from the WG last >> call. > > Yes please. > >> 3. The I-D should be progressed as an informational RFC > > Yes. This is advisable. > > Please update the I-D and submit it. I will then forward it to Alex > for AD > review. > > Cheers, > Adrian > From owner-ccamp@ops.ietf.org Wed May 25 16:00:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17538 for ; Wed, 25 May 2005 16:00:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db2MC-0007yh-0F for ccamp-archive@ietf.org; Wed, 25 May 2005 16:20:00 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Db1vf-000PHL-B6 for ccamp-data@psg.com; Wed, 25 May 2005 19:52:35 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Db1ve-000PH3-I0 for ccamp@ops.ietf.org; Wed, 25 May 2005 19:52:34 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15854; Wed, 25 May 2005 15:52:32 -0400 (EDT) Message-Id: <200505251952.PAA15854@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-loose-path-reopt-01.txt Date: Wed, 25 May 2005 15:52:31 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --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 : Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-loose-path-reopt-01.txt Pages : 13 Date : 2005-5-25 This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering LSPs. A loosely routed LSP is defined as one that does not contain a full explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no ERO, with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR). This document proposes a mechanism that allows a TE LSP head-end LSR to trigger a new path re- evaluation on every hop having a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path in use) or that the TE LSP must be reoptimized because of some maintenance required on the TE LSP path. The proposed mechanism applies to the cases of intra and inter-domain (IGP area or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-loose-path-reopt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-25160028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-loose-path-reopt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-25160028.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu May 26 03:34:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06481 for ; Thu, 26 May 2005 03:34:22 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbDBN-0001PS-AL for ccamp-archive@ietf.org; Thu, 26 May 2005 03:53:34 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbCiG-000EBq-Tj for ccamp-data@psg.com; Thu, 26 May 2005 07:23:28 +0000 Received: from [80.168.70.150] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbCiE-000EBS-O1; Thu, 26 May 2005 07:23:27 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DbCiC-000Eb8-Rl; Thu, 26 May 2005 08:23:24 +0100 From: "Adrian Farrel" To: zinin@psg.com Cc: ccamp@ops.ietf.org, iesg-secretary@ietf.org, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: draft-ietf-ccamp-loose-path-reopt-01.txt ready for AD review Date: Thu, 26 May 2005 08:23:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.84 Message-Id: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Alex, draft-ietf-ccamp-loose-path-reopt-01.txt is ready for AD review and progress towards being an Informational RFC. It has been through CCAMP working group last call and has been updated to my satisfaction. Note that some IPR issues were raised. After discussion, the I-D has been moved to the Informational track, and a note (section 1) has been added to explain how the procedures are entirely optional. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu May 26 15:55:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29386 for ; Thu, 26 May 2005 15:55:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbOkq-0002Rg-Bt for ccamp-archive@ietf.org; Thu, 26 May 2005 16:14:59 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbOIo-000NgZ-Ei for ccamp-data@psg.com; Thu, 26 May 2005 19:45:58 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbOIm-000NgI-J0 for ccamp@ops.ietf.org; Thu, 26 May 2005 19:45:56 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26881; Thu, 26 May 2005 15:45:53 -0400 (EDT) Message-Id: <200505261945.PAA26881@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-02.txt Date: Thu, 26 May 2005 15:45:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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 Based Segment Recovery Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-gmpls-segment-recovery-02.txt Pages : 24 Date : 2005-5-26 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. This document also updates the handling of Notify_Request objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-segment-recovery-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-26161622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-segment-recovery-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-26161622.I-D@ietf.org> --OtherAccess-- --NextPart-- From EdgarWarren@calanthe.com Thu May 26 21:13:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28770 for ; Thu, 26 May 2005 21:13:50 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbTin-0003uU-LN for ccamp-archive@ietf.org; Thu, 26 May 2005 21:33:12 -0400 Received: from 137-29-235-201.fibertel.com.ar ([201.235.29.137]) by mx2.foretec.com with smtp (Exim 4.24) id 1DbSUI-0001gK-Td for ccamp-archive@ietf.org; Thu, 26 May 2005 20:14:10 -0400 Received: from MmnR@localhost by kaRe.int (8.11.6/8.11.6); Fri, 27 May 2005 02:20:12 -0600 Message-ID: <7upePlM7XmXvU7cFLDCLaHr4H@manzanillos.com> From: "Reed Wright" Reply-To: "Reed Wright" To: casandra.craig@ietf.org Subject: Thousands of academic software titles, 80% off, Instant Download Date: Fri, 27 May 2005 03:23:12 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: EdgarWarren@calanthe.com Content-Type: multipart/mixed; boundary="--e0bMGDcJH5J58eljm3x" X-Spam-Score: 3.6 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 zP6j ----e0bMGDcJH5J58eljm3x Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 4
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

<= td width=3D4>  Microsoft=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
&nbs= p;4 Norton Antivirus 2005
 5 Flash MX 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
10 Adobe Premiere
 = See more by this manufacturer=
  
&= nbsp;  Apple Software
  Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
<= td vAlign=3Dtop noWrap>
Choose:
<= tr>
 
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Featur= es:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems u= sing enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
  • = More than 20 preformatted business reports
    • Sales Rank: #1
    Ship= ping: International/US or via instant download
    Date Coupon Expi= res: June 30th, 2005
    Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
    <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
    Microsoft Windows XP= Professional or Longhorn Edition
    Microsoft
    Choose:
     

    <= a href=3Dhttp://expansionsoft.com/?m>

    $279.00
    Price:$49.99
    You Save= :$229.01 (85%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Acces= sories  |  Other Versi= ons

    Features:=

    • Designed for businesses o= f all sizes
    • Manage digital p= ictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and folders
    • Built-in voice, video, and insta= nt messaging support
    • Integra= tion with Windows servers and management solutions

    Sales Rank: #2
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    Choose:
     

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

    <= p>Features:

      Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
    • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
    • Create or modify ph= otos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping:= International/US or via instant download
    Date Coupon Expires:<= /b> June 30th, 2005
    Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

----e0bMGDcJH5J58eljm3x-- From owner-ccamp@ops.ietf.org Fri May 27 14:06:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07701 for ; Fri, 27 May 2005 14:06:13 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjWg-0002xI-FF for ccamp-archive@ietf.org; Fri, 27 May 2005 14:25:42 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dbj6b-000KBb-5X for ccamp-data@psg.com; Fri, 27 May 2005 17:58:45 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dbj6Y-000KB8-U6 for ccamp@ops.ietf.org; Fri, 27 May 2005 17:58:43 +0000 Received: from ib (vpn16.atlanta.movaz.com [172.18.0.16]) by jera.movaz.com (Postfix) with SMTP id 66F141542; Fri, 27 May 2005 13:58:41 -0400 (EDT) Message-ID: <008201c562e5$b6329bd0$6501a8c0@movaz.com> From: "Igor Bryskin" To: "Kireeti Kompella" , References: <20050524134652.P88814@kummer.juniper.net> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Fri, 27 May 2005 13:58:38 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Hi, I have several comments on the document. Section 1.1 Nested domains: For further consideration of nested domains see [MRN] MRN does not cover nested domains, ITU hierarchical routing does. This is a hole in (G)MPLS TE Section 2.1 LSP Nesting FA and FA-LSP are not accurate terms for describing LSP nesting, which is using an LSP created in one network layer as a data link in other layer(s). H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a TE link, the link is not necessarily FA, that is, it may require direct IGP adjacency between its ends to provide necessary control plane connectivity. Thus, the abstract: Note also that the IGP/EGP routing topology is maintained unaffected by the LSP connectivity and TE links introduced by FA LSPs. That is, the routing protocols do not exchange messages over the FA LSPs, and such LSPs do not create routing adjacencies between routers. is not correct in the case when an H-LSP created in one domain is advertised as a TE link into a different domain Section 2.3 LSP stitching Again, a stitching segment created in one domain and advertised as a TE link into a different domain is not an FA, it is just a "regular" TE link not distinguishable from a TE link supported by static data link(s) Section 3.3 Domain Boundary Computation I'd like to see a clause here stating about necessity of avoiding loops with the LSP head segment during domain boundary path computation and describing some mechanisms how this could be achieved. Section 5.10 Applicability to Non-Packet Technologies I'd like to see in this section a statement saying that earlier described FRR does not work well in non-packet environments and other techniques should be considered for inter-domain service recovery. One of such techniques is the segment recovery, which IMHO works equally well in packet and non-packet environments Igor ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Tuesday, May 24, 2005 4:49 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > Hi All, > > This starts a two week CCAMP WG Last call on: > draft-ietf-ccamp-inter-domain-framework-02.txt > > Please send your comments to the list (preferably) or to the authors > latest by June 7, 23:59 GMT. > > Thanks, > Kireeti. > ------- > > ---------- Forwarded message ---------- > Date: Mon, 23 May 2005 15:39:15 -0400 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: ccamp@ops.ietf.org > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Framework for Inter-Domain MPLS Traffic Engineering > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-inter-domain-framework-02.txt > Pages : 19 > Date : 2005-5-23 > From info@mail.kaibutsu-kun.com Sat May 28 04:47:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06298 for ; Sat, 28 May 2005 04:47:44 -0400 (EDT) Received: from [218.187.44.168] (helo=mail.kaibutsu-kun.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DbxHt-0007SD-Fc for ccamp-archive@ietf.org; Sat, 28 May 2005 05:07:23 -0400 Received: (qmail 3472 invoked by uid 510); 28 May 2005 12:54:45 +0900 Date: 28 May 2005 12:54:45 +0900 Message-ID: <20050528035445.3470.qmail@mail.kaibutsu-kun.com> From: info@kaibutsu-kun.com To: ccamp-archive@ietf.org Subject: １０分で十分です X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 貴方は当グループ(女性運営)の特別男性会員と選ばれたことのお知らせです。 　　　　　　　　　 ※認証コード　<3305> このメールを開封して２４時間以内に会員登録(無料)を済ませれば、なんと？ 　　　　　　　　　…【10分】で待ち合わせ… 　　　　　　　　　　↓　↓　↓　↓　↓ 　　　　　　　　　http://www.jumpb3.net/?10min 　▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼ 　　面倒な手順、不要な機能は全て廃止。登録から出会いまで【10分】あれ 　ば充分です！！当サイト自慢な地域別の★近所ナビ★で市町村単位まで検 　索できます。貴方にも必ずお相手が出来る事を私がお約束できます。（雑 　誌等にも取り上げられ利用者も急増中　UP） 　　　　　　　　　http://www.jumpb3.net/?10min 　▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲ ※内緒です。 無料の【認証コード】 完全無料で登録、更にご近所の直連絡方法最大１０名分ゲットできる【認証 コード】は<3305>番です。登録の際にニックネームに明記して頂くと上記権利 が発生します。 ＜注意＞ 当サイトの人数限定企画なので、自分の認証コードを他人に漏れないよう御注意下さい。 From owner-ccamp@ops.ietf.org Sat May 28 05:52:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09162 for ; Sat, 28 May 2005 05:52:26 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbyIW-0000Dh-NJ for ccamp-archive@ietf.org; Sat, 28 May 2005 06:12:06 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dbxpe-000Ajh-KT for ccamp-data@psg.com; Sat, 28 May 2005 09:42:14 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dbxpd-000AjF-R3; Sat, 28 May 2005 09:42:13 +0000 Received: from du-069-0035.access.clara.net ([217.158.132.35] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1Dbxpb-000Iyd-II; Sat, 28 May 2005 10:42:12 +0100 Message-ID: <006901c56369$d4fb92e0$23849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "WG Milestone Tracker" Subject: draft-ietf-ccamp-gmpls-segment-recovery-02.txt ready for AD review Date: Sat, 28 May 2005 10:28:30 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi Alex, draft-ietf-ccamp-gmpls-segment-recovery-02.txt is ready for AD review and moving forward through the process as a Standards Track ID. The draft has been through CCAMP working group last call and has been updated to my satisfaction (but please note that I am a co-author). You may wish to handle this I-D together with draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt since they share a new version of the Protection object. Thanks, Adrian From owner-ccamp@ops.ietf.org Sat May 28 18:26:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09505 for ; Sat, 28 May 2005 18:26:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcA4A-00012N-U9 for ccamp-archive@ietf.org; Sat, 28 May 2005 18:46:05 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dc9ZL-00081X-JH for ccamp-data@psg.com; Sat, 28 May 2005 22:14:11 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dc9ZF-000815-BO for ccamp@ops.ietf.org; Sat, 28 May 2005 22:14:07 +0000 Message-ID: <4298ED2B.7010302@psg.com> Date: Sun, 29 May 2005 00:14:03 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: comments on draft-ietf-ccamp-inter-domain-framework-02.txt Content-Type: multipart/mixed; boundary="------------050500030200070008040305" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, LONGWORDS autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: eff26143627d807d5f980d5aa3bc54ca This is a multi-part message in MIME format. --------------050500030200070008040305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit some comments on this document: 1. introduction refers to a separate document - but without much precision - 2. introduction "However, domains of computational responsibility may also exist as sub-domains of areas or ASs. Wholly or partially overlapping domains are not within the scope of this document." how the second sentence should be interpreted wrt to the previous one ? 3. section 2 refers to "Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple TE LSP types." what are these LSP types ? i think this document is the right place to disambiguate the signaling methodology from 4. section 2.1 "Furthermore, the mapping (inheritance rules) between attributes of the nested and FA LSPs (including bandwidth) may be statically pre-configured or, for on-demand FA LSPs, may be dynamic according to the properties of the nested LSPs." worth indicating here that even in the dynamic case inheritance from the properties of the nested LSP(s) can be complemented by local or domain-wide policy rules 5. section 2.1 "During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP." the same applies for the FILTER_SPEC object and any other object that has an end-to-end significance 6. section 2.2 this notion of contiguous LSP is unclear, if i correctly understand the definition i can not establish a contiguous packet LSP using PSC links that are themselves TDM LSPs - why this restriction ? 7. section 2.4 could be interesting to have better insight on RRO methods to select signaling method "It may be desirable in this case for the choice of the various methods to be indicated along the path perhaps through the RRO." 8. section 2.5 refers to interoperability but in which sense ? object support or functionality 9. section 3.2 indeed the destination must be provided but i suggest to indicate the corr. object(s) i.e. Session, ERO subobjects, etc. 10. section 3.2.1 having full visibility provides the capacity to achieve optimality - at least for a given period of time - in brief, it is not a sufficient condition 11. section 3.2.2 i guess the proposed formats are not meant to be exchaustive (would be worth indicating this) 12. section 3.3 3rd paragraph is indeed expressing ERO construction per 3209, but then how to interpreet second bullet of the alternative presented in section 3.2.2. 13. section 3.4 "The selection of PCE(s) may be driven by static configuration or the dynamic discovery by means of IGP or BGP extensions." would it be possible to detail in which context BGP PCE discovery would be appropriate and the corresponding mechanism applicable 14. section 3.4.2 paragraph 2 discusses (again) optimality issues but in the context of a section that speaks about confidentiality - not sure this is the best place in the document to do so - 15. section 3.5 what is the real purpose of this section ? lot of things is said about conditions prevailing in multi-domain environments but very few is said about what could be a baseline on "optimal multi-domain path" - may be worth considering the last paragraph only - 16. section 4 would it be possible to expand on "end-point" reachability information exchanges - which is at the end the only mandatory information needed the following "Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to BGP, and how these may be fed to the IGPs. ..." is again focusing on TE info processing 17. section 5.1 if this section is dedicated to re-optmization - and considered as an advanced mechanism - details included as part of section 3.4.2 should be moved in this section 18. section 5.1 " Note also that where multiple diverse paths are applied end-to-end (i.e. not simply within protection domains - see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path." the notion of diversity is unclear in this sentence i.e. diverse from ? 19. section 5.4 would it be possible to detail the following sentence, in particular, when FRR is used in combination with LSP stitching "The techniques that must be employed to use Fast Reroute for the different methods of signaling LSPs identified in section 2 differ considerably." 20. section 5.5 would be interesting to know what is meant by "easier" in the following sentence "The problem is generally considered to be easier and more efficient when the diverse paths can be computed 'simultaneously' on the fullest set of information." it would also be interesting to know what is meant by "Domain ID" in the context of the following sentence "The former might be identified using a combination of domain ID and an SRLG ID that is administered by the domain." in particular if SRLGs are confined within a domain adding a domain id to the SRLG ID would only be useful if SRLG id values are not unique across domains but the latter would then be expected to share that information - is that the intention ? 21. Section 5.8 the major issue is whether end-points are supportive of the capability - this should be highlighted in this section - editorial: this document refers to TE LSP and sometimes to LSP is there any specific different or just a contraction ? i am asking this because in the context of a document that speaks about Traffic Engineering this is not necessarily clear --------------050500030200070008040305 Content-Type: text/plain; name="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt" Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt" Content-Transfer-Encoding: 7bit Network Working Group Adrian Farrel IETF Internet Draft Olddog Consulting Proposed Status: Informational Expires: November 2005 Jean-Philippe Vasseur Cisco Systems, Inc. Arthi Ayyangar Juniper Networks May 2005 A Framework for Inter-Domain MPLS Traffic Engineering draft-ietf-ccamp-inter-domain-framework-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Farrel, Vasseur and Ayyangar Page 1 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 Contents 1. Introduction ............................................... 3 1.1. Nested Domains ......................................... 3 1.2. Conventions used in this document ...................... 4 2. Signaling Options .......................................... 4 2.1. LSP Nesting ............................................ 4 2.2. Contiguous LSP ......................................... 5 2.3. LSP Stitching .......................................... 5 2.4. Hybrid Methods ......................................... 5 2.5. Control of Downstream Choice of Signaling Method ....... 6 3. Path Computation Techniques ................................ 6 3.1. Management Configuration ............................... 6 3.2. Head End Computation ................................... 6 3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.2. Partial Visibility Computation ..................... 7 3.2.3. Local Domain Visibility Computation ................ 7 3.3. Domain Boundary Computation ............................ 8 3.4. Path Computation Element ............................... 8 3.4.1. Multi-Domain Visibility Computation ................ 9 3.4.2. Path Computation Use of PCE When Preserving Confidentiality .................................... 9 3.4.3. Per-Domain Computation Servers ..................... 9 3.5. Optimal Path Computation ............................... 9 4. Distributing Reachability and TE Information .............. 10 5. Comments on Advanced Functions ............................ 11 5.1. LSP Re-Optimization ................................... 11 5.2. LSP Setup Failure ..................................... 12 5.3. LSP Repair ............................................ 12 5.4. Fast Reroute .......................................... 12 5.5. Comments on Path Diversity ............................ 13 5.6. Domain-Specific Constraints ........................... 14 5.7. Policy Control ........................................ 14 5.8. Inter-domain OAM ...................................... 15 5.9. Point-to-Multipoint ................................... 15 5.10. Applicability to Non-Packet Technologies ............. 15 6. Security Considerations ................................... 15 7. IANA Considerations ....................................... 16 8. Acknowledgements .......................................... 16 9. Intellectual Property Considerations ...................... 16 10. Normative References ..................................... 16 11. Informational References ................................. 17 12. Authors' Addresses ....................................... 18 13. Full Copyright Statement ................................. 19 Farrel, Vasseur and Ayyangar Page 2 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 1. Introduction The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and [INTER-AS]. Various proposals have subsequently been made to address some or all of these requirements through extensions to the RSVP-TE and IGP (ISIS, OSPF) protocols and procedures. This document introduces the techniques for establishing TE LSPs across multiple domains. The functional components of these techniques are separated into the mechanisms for discovering reachability and TE information, for computing the paths of LSPs, and for signaling the LSPs. Note that the aim of this document is not to detail each of those techniques which are covered in separate documents, but rather to propose a framework for inter-domain MPLS Traffic Engineering. Note that in the remainder of this document, the term 'MPLS Traffic Engineering' is used equally to apply to MPLS and GMPLS traffic. Specific issues pertaining to the use of GMPLS in inter-domain environments (for example, policy implications of the use of the Link Management Protocol [LMP] on inter-domain links) these are covered in a separate document. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. However, domains of computational responsibility may also exist as sub-domains of areas or ASs. Wholly or partially overlapping domains are not within the scope of this document. 1.1. Nested Domains Nested domains are outside the scope of this document. It may be that some domains that are nested administratively or for the purposes of address space management can be considered as adjacent domains for the purposes of this document, however the fact that the domains are nested is then immaterial. In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is wholly contained in Domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A. For further consideration of nested domains see [MRN] Farrel, Vasseur and Ayyangar Page 3 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Signaling Options Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple TE LSP types. The choice may further depend on the application to which the TE LSPs are put and the nature, topology and switching capabilities of the network. A comparison of the usages of the different signaling options is beyond the scope of this document and should be the subject of a separate applicability statement. 2.1. LSP Nesting Forwarding Adjacencies (FAs) are introduced and explained in detail in [HIER]. No further description is necessary in this document. FAs can be used in support of inter-domain TE LSPs. In particular, an FA may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the FA LSP could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. The technique of carrying one TE LSP within another is termed LSP nesting. An FA may provide a TE LSP tunnel to transport (i.e. nest) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a one-to-one mapping. The signaling trigger for the establishment of an FA LSP may be the receipt of a signaling request for the TE LSP that it will carry, or may be a management action to 'pre-engineer' a domain to be crossed by TE LSPs that would be used as FAs by the traffic that has to traverse the domain. Furthermore, the mapping (inheritance rules) between attributes of the nested and FA LSPs (including bandwidth) may be statically pre-configured or, for on-demand FA LSPs, may be dynamic according to the properties of the nested LSPs. Note that a hierarchical LSP may be constructed to span multiple domains or parts of domains. However, how or whether such an LSP could be advertised as an FA that spans domains is open for study. The end points of a hierarchical LSP are not necessarily on domain boundaries, so nesting is not limited to domain boundaries. Farrel, Vasseur and Ayyangar Page 4 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 Note also that the IGP/EGP routing topology is maintained unaffected by the LSP connectivity and TE links introduced by FA LSPs. That is, the routing protocols do not exchange messages over the FA LSPs, and such LSPs do not create routing adjacencies between routers. During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP. 2.2. Contiguous LSP A single contiguous LSP is established from ingress to egress in a single signaling exchange. No further LSPs are required to be established to support this LSP. Signaling occurs between adjacent neighbors only (no tunneling), and hop-by-hop signaling is used. 2.3. LSP Stitching LSP Stitching is described in [STITCH]. In the LSP stitching model separate LSPs (referred to as a TE LSP segments) are established and are "stitched" together in the data plane so that a single end-to-end label switched path is achieved. The distinction is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination. LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. The signaling trigger for the establishment of a TE LSP segment may be the establishment of the previous TE LSP segment, the receipt of setup request for TE LSP that it plans to stitch to a local TE LSP segment, or may be a management action. LSP segments may be managed as FAs and advertised as TE links. 2.4. Hybrid Methods There is nothing to prevent the mixture of signaling methods described above when establishing a single, end-to-end, inter-domain TE LSP. It may be desirable in this case for the choice of the various methods to be indicated along the path perhaps through the RRO. If there is a desire to restrict which methods are used, this MUST be signaled as described in the next section. Farrel, Vasseur and Ayyangar Page 5 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 2.5. Control of Downstream Choice of Signaling Method Notwithstanding the previous section, an ingress LSR MAY wish to restrict the signaling methods applied to a particular LSP at domain boundaries across the network. Such control, where it is required, may be achieved by the definition of appropriate new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to provide this level of control, the functional requirement to control the way in which the network delivers a service must be established and due consideration must be given to the impact on interoperability. 3. Path Computation Techniques The discussion of path computation techniques within this document is limited significantly to the determination of where computation may take place and what components of the full path may be determined. The techniques used are closely tied to the signaling methodologies described in the previous section in that certain computation techniques may require the use of particular signaling approaches and vice versa. Any discussion of the appropriateness of a particular path computation technique in any given circumstance is beyond the scope of this document and should be described in a separate applicability statement. Path computation algorithms are firmly out of scope of this document. 3.1. Management Configuration Path computation may be performed by offline tools or by a network planner. The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and encoded by the ingress LSR as an ERO on the Path message that is sent out. There is no reason why the path provided by the operator should not span multiple domains if the relevant information is available to the planner or the offline tool. The definition of what information is needed to perform this operation and how that information is gathered, is outside the scope of this document. 3.2. Head End Computation The head end, or ingress, LSR may assume responsibility for path computation when the operator supplies part or none of the explicit path. The operator MUST, in any case, supply at least the destination address (egress) of the LSP. Farrel, Vasseur and Ayyangar Page 6 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 3.2.1. Multi-Domain Visibility Computation If the ingress has sufficient visibility of the topology and TE information for all of the domains across which it will route the LSP to its destination then it may compute and provide the entire path. The quality of this path (that is, its optimality as discussed in section 3.5) is best if the ingress has full visibility into all relevant domains rather than just sufficient visibility to provide some path to the destination. Extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.2. Partial Visibility Computation It may be that the ingress does not have full visibility of the topology of all domains, but does have information about the connectedness of the domains and the TE resource availability across the domains. In this case, the ingress is not able to provide a fully specified strict explicit path from ingress to egress. However, the ingress can supply an explicit path that comprises: - explicit hops from ingress to the local domain boundary - loose hops representing the domain entry points across the network - a loose hop identifying the egress. Alternatively, the explicit path may be expressed as: - explicit hops from ingress to the local domain boundary - strict hops giving abstract nodes representing each domain in turn - a loose hop identifying the egress. These two explicit path formats may be mixed. This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3. As with the multi-domain visibility option, extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.3. Local Domain Visibility Computation A final possibility for ingress-based computation is that the ingress LSR has visibility only within its own domain, and connectivity information only as far as determining one or more domain exit points that may be suitable for carrying the LSP to its egress. In this case the ingress builds an explicit path that comprises just: - explicit hops from ingress to the local domain boundary - a loose hop identifying the egress. Farrel, Vasseur and Ayyangar Page 7 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 3.3. Domain Boundary Computation If the partial explicit path methods described in sections 3.2.2 or 3.2.3 are applied then the LSR at each domain boundary is responsible for ensuring that there is sufficient path information added to the Path message to carry it at least to the next domain boundary (that is, out of the new domain). If the LSR at the domain boundary has full visibility to the egress then it can supply the entire explicit path. Note however, that the ERO processing rules of [RFC3209] state that it SHOULD only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO) and, of course, MUST NOT insert ERO subobjects immediately before a strict hop. If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2) it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO. If the LSR at the domain boundary has only local visibility into the immediate domain it will simply add information to the ERO to carry the Path message as far as the next domain boundary. 3.4. Path Computation Element The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information - see section 4. An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [PCE]. There may be either a centralized PCE, or multiple PCEs (each having local visibility and collaborating in a distributed fashion to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources as would be used by LSRs in the previous paragraph, or though other means. Each LSR called upon to perform path computation (and even the offline management tools described in section 3.1) may abdicate the task to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or the dynamic discovery by means of IGP or BGP extensions. Farrel, Vasseur and Ayyangar Page 8 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 3.4.1. Multi-Domain Visibility Computation A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case it is able to supply a full explicit path as in section 3.2.1. 3.4.2. Path Computation Use of PCE When Preserving Confidentiality Note that although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g to preserve confidentiality) that the full path is not provided to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are required to make further requests for each successive segment of the path. In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute the best path on each request or at regular intervals. It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that normally operational between domains. 3.4.3. Per-Domain Computation Elements A third way that PCEs may be used is simply to have one (or more) per domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE. This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE. 3.5. Optimal Path Computation An optimal route might be defined as the route that would be computed in the absence of domain boundaries. Another constraint to the definition of 'optimal' might be to reduce or limit the number of domains crossed by the LSP. It is easy to construct examples that show that partitioning a network into domains, and the resulting loss or aggregation of routing information may lead to the computation of routes that are other than optimal. It is impossible to guarantee optimal routing in the presence of aggregation / abstraction / summarization of routing information. Farrel, Vasseur and Ayyangar Page 9 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 It is beyond the scope of this document to define what is an optimum path for an inter-domain TE LSP. This debate is abdicated in favor of requirements documents and applicability statements. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6). 4. Distributing Reachability and TE Information Traffic Engineering information is collected into a TE Database (TED) on which path computation algorithms operate either directly or by first constructing a network graph. The path computation techniques described in the previous section make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains. Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784]. In cases where two domains are interconnected by one or more links (that is, the domain boundary falls on a link rather than on a node), there SHOULD be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would facilitate better path computation and reduce TE-related crankbacks on these links. Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way, or two way. Where information needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain. It could be possible that an LSR that performs path computation (for example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to FAs across other domains, or the information may be aggregated or abstracted). Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to BGP, and how these may be fed to the IGPs. Techniques for inter-domain TE aggregation are also for further study. However, it must be noted that any extensions that cause a significant increase in the amount of processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of information flooded (such as detailed TE information) need to be treated with extreme caution Farrel, Vasseur and Ayyangar Page 10 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 and compared carefully with the scaling requirements expressed in [INTER-AREA] and [INTER-AS]. 5. Comments on Advanced Functions This section provides some non-definitive comments on the constraints placed on advanced MPLS TE functions by inter-domain MPLS. It does not attempt to state the implications of using one inter-domain technique or another. Such material is deferred to appropriate applicability statements where statements about the capabilities of existing or future signaling, routing and computation techniques to deliver the functions listed should be made. 5.1. LSP Re-Optimization Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (where no attempt is made in this document to define 'preferable' as no attempt was made to define 'optimal'). Make-before-break techniques are usually applied to ensure that traffic is disrupted as little as possible. The Shared Explicit style is usually used to avoid double booking of network resources. Re-optimization may be available within a single domain. Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains. Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized. The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example bandwidth) of an LSP. This trigger MUST be applied to the point in the network that requests re-computation and controls re-optimization and may require additional signaling. Note also that where multiple diverse paths are applied end-to-end (i.e. not simply within protection domains - see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of Farrel, Vasseur and Ayyangar Page 11 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re-optimization path calculations performed in another domain. 5.2. LSP Setup Failure When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP. In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary. If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error MUST be reported back to the previous or head-end domain. Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of confidentiality although crankback aggregation may be applicable at domain boundaries. Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE]. When requested by signaling, the failure may also be systematically reported to the head-end LSR. 5.3. LSP Repair An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or for handling setup failures (see previous two sections). Fast Reroute may also be used (see below). 5.4. Fast Reroute MPLS Traffic Engineering Fast Reroute ([FRR]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The Farrel, Vasseur and Ayyangar Page 12 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 node immediately upstream of the failure (called the PLR - Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource. In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [FRR] specifies two distinct modes of operation referred to as the "one to one mode" and the "facility back-up mode". The failure scenarios specific to inter-domain TE are as follows: - Failure of a domain edge node that is present in both domains. There are two sub-cases: - The PLR and the MP are in the same domain - The PLR and the MP are in different domains. - Failure of a domain edge node that is only present in one of the domains. - Failure of an inter-domain link. The techniques that must be employed to use Fast Reroute for the different methods of signaling LSPs identified in section 2 differ considerably. These should be explained further in applicability statements of, in the case, of a change in base behavior, in implementation guidelines specific to the signaling techniques. Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re-optimization (for example the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event. It is important to note that Fast Reroute techniques are only applicable to packet switching networks because other network technologies cannot apply label stacking within the same switching type. Segment protection [SEG-PROT] provides a suitable alternative that is applicable to packet and non-packet networks. 5.5. Comments on Path Diversity Diverse paths may be required in support of load sharing and/or protection. Such diverse paths may be required to be node diverse, link diverse, fully path diverse (that is, link and node diverse), or SRLG diverse. Diverse path computation is a classic problem familiar to all graph theory majors. The problem is compounded when there are areas of Farrel, Vasseur and Ayyangar Page 13 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 'private knowledge' such as when domains do not share topology information. The problem is generally considered to be easier and more efficient when the diverse paths can be computed 'simultaneously' on the fullest set of information. That being said, various techniques (out of the scope of this document) exist to ensure end-to-end path diversity across multiple domains. Many network technologies utilize 'protection domains' because they fit well with the capabilities of the technology. As a result, many domains are operated as protection domains. In this model, protection paths converge at domain boundaries. Note that the question of SRLG identification is not yet fully answered. There are two classes of SRLG: - those that indicate resources that are all contained witin one domain - those that span domains. The former might be identified using a combination of domain ID and an SRLG ID that is administered by the domain. The latter requires a wider scope to the SRLG ID, and it is not clear how this would be administered. 5.6. Domain-Specific Constraints While the meaning of certain constraints, like bandwidth, can be assumed to be constant across different domains, other TE constraints (such as resource affinity, color, metric, priority, etc.) may have different meanings in different domains and this may impact the ability to support DiffServ-aware MPLS, or to manage pre-emption. In order to achieve consistent meaning and LSP establishment, this fact must be considered when performing constraint-based path computation or when signaling across domain boundaries. A mapping function can be derived for most constraints based on policy agreements between the Domain administrators. The details of such a mapping function are outside the scope of this document, but it is important to note that the default behavior MUST either be that a constant mapping is applied or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules. 5.7. Policy Control Domain boundaries are natural points for policy control. There is little to add on this subject except to note that a TE LSP that cannot be established on a path through one domain because of a policy applied at the domain boundary, may be satisfactorily Farrel, Vasseur and Ayyangar Page 14 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 established using a path that avoids the demurring domain. In any case, when a TE LSP signaling attempt is rejected due to non-compliance with some policy constraint, this SHOULD be reflected to the ingress LSR. 5.8. Inter-domain OAM Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to-end OAM. The different signaling mechanisms described above may need refinements to [LSPPING], and [BFD-MPLS], etc., to gain full end-to-end visibility. These protocols should, however, be considered in the light of confidentiality requirements. Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for confidentiality or other policy reasons. 5.9. Point-to-Multipoint Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of scope of this document. They may be covered by other documents dependent on the details of MPLS TE P2MP solutions. 5.10. Applicability to Non-Packet Technologies Non-packet switching technologies may present particular issues for inter-domain LSPs. While packet switching networks may utilize control planes built on MPLS or GMPLS technology, non-packet networks are limited to GMPLS. The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS]. 6. Security Considerations Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], but requirements for inter-domain security are, if anything, more significant. Authentication techniques identified for use with RSVP-TE can only operate across domain boundaries if there is coordination between the administrators of those domains. Farrel, Vasseur and Ayyangar Page 15 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 Confidentiality may also be considered to be security factors. Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections. 7. IANA Considerations This document makes no requests for any IANA action. 8. Acknowledgements The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document. Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their review and suggestions on the text. 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Farrel, Vasseur and Ayyangar Page 16 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 11. Informational References [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes, work in progress. [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work in progress. [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", draft-ietf-ccamp-crankback, work in progress. [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, draft-ietf-ccamp-rsvp-te-exclude-route, work in progress. [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, work in progress. [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress. [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-req, work in progress. Farrel, Vasseur and Ayyangar Page 17 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-te-req, work in progress. [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness in MPLS", draft-ietf-mpls-lsp-ping, work in progress. [MRN] K. Shiomoto, et al., "Requirements for GMPLS-based multi-region and multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay, work in progress. [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, A., "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery, work in progress. [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching, work in progress. 12. Authors' Addresses Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Arthi Ayyangar Juniper Networks, Inc 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA Email: arthi@juniper.net Farrel, Vasseur and Ayyangar Page 18 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 13. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Farrel, Vasseur and Ayyangar Page 19 --------------050500030200070008040305-- From WarrenGordon@healthiness.net Sat May 28 20:41:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15359 for ; Sat, 28 May 2005 20:41:14 -0400 (EDT) Received: from chello080108112111.17.11.vie.surfer.at ([80.108.112.111]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DcCAi-0003NV-UA for ccamp-archive@ietf.org; Sat, 28 May 2005 21:01:01 -0400 Received: from Gdf@localhost by dPN9.int (8.11.6/8.11.6); Sun, 29 May 2005 05:48:21 -0200 Message-ID: From: "Hallie Colon" Reply-To: "Hallie Colon" To: casandra.craig@ietf.org Subject: OEM software wholesale savings Adobe Date: Sun, 29 May 2005 04:52:21 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: WarrenGordon@healthiness.net Content-Type: multipart/mixed; boundary="--Wcn8rVhYcWIhk55oWC" X-Spam-Score: 3.9 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 IHj ----Wcn8rVhYcWIhk55oWC Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Z
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
5

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Window= s XP Pro
 3 Adobe Cre= ative Suite Premium
 4 Norton Antivirus 2005
  Flash MX 2004
 6 Corel Draw 12
 7 Adobe = Acrobat 7.0
 8 Window= s 2003 Server
 9 Alias = Maya 6 Wavefrt
 10 Adobe = Premiere
  See more= by this manufacturer
 <= /td>  Microsoft<= /td>
   Apple Software
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
<= /td>



Microsoft Offi= ce Professional Edition *2003*
Microsoft
Choose= :
&= nbsp;
=
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze= and manage business information using Access databases
  • Exchange data with other systems using enhance= d XML technology
  • Control inf= ormation sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: Int= ernational/US or via instant download
Date Coupon Expires: June= 30th, 2005
Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
Microsoft Windows XP Professional or = Longhorn Edition
Microsoft =
Choose:
<= /td> <= /a>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: June 30th, 2005
Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9= 0
Adobe=
Choose:=
 

List Price:<= /td> $599.00
Price:$69.99
You Save:$529.01 (90%)



= Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

----Wcn8rVhYcWIhk55oWC-- From owner-ccamp@ops.ietf.org Sun May 29 04:05:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00447 for ; Sun, 29 May 2005 04:05:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcJ6f-0008OR-SE for ccamp-archive@ietf.org; Sun, 29 May 2005 04:25:14 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcIcw-0000fM-V1 for ccamp-data@psg.com; Sun, 29 May 2005 07:54:30 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcIcs-0000eF-Pn; Sun, 29 May 2005 07:54:27 +0000 Message-ID: <42997530.2090802@psg.com> Date: Sun, 29 May 2005 09:54:24 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) References: <20050524134652.P88814@kummer.juniper.net> <008201c562e5$b6329bd0$6501a8c0@movaz.com> In-Reply-To: <008201c562e5$b6329bd0$6501a8c0@movaz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Igor Bryskin wrote: > Hi, > > I have several comments on the document. > > Section 1.1 Nested domains: > > For further consideration of nested domains see [MRN] > > MRN does not cover nested domains, ITU hierarchical routing does. This is a > hole in (G)MPLS TE not sure to understand your comment here, in particular when considering "switching capability domains" - i suggest you take a look for instance at section 5.1.7 of MRN that provides you an example if this can help understanding > Section 2.1 LSP Nesting > > FA and FA-LSP are not accurate terms for describing LSP nesting, which is > using an LSP created in one network layer as a data link in other layer(s). > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a TE > link, the link is not necessarily FA, that is, it may require direct IGP > adjacency between its ends to provide necessary control plane connectivity. note: a hierarchical LSP does also translate as (using your words) "LSP created in one network layer as a data link in other layer(s)" the whole discussion point here is about the control plane instance and relationship - > Thus, the abstract: > > Note also that the IGP/EGP routing topology is maintained unaffected by > the LSP connectivity and TE links introduced by FA LSPs. That is, the > routing protocols do not exchange messages over the FA LSPs, and such LSPs > do not create routing adjacencies between routers. is not correct in the > case when an H-LSP created in one domain is advertised as a TE link into a > different domain so, the document is consistent from that perspective, FAs are not used for exchanging routing informations - but the previous paragraph must be reflect this since it makes use of the term "hierarchical LSP" > Section 2.3 LSP stitching > > Again, a stitching segment created in one domain and advertised as a TE link > into a different domain is not an FA, it is just a "regular" TE link not > distinguishable from a TE link supported by static data link(s) indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." - but not for the reason you have indicated - simply because there is no notion of nesting when considering an LSP segment > Section 3.3 Domain Boundary Computation > > I'd like to see a clause here stating about necessity of avoiding loops with > the LSP head segment during domain boundary path computation and describing > some mechanisms how this could be achieved. > > Section 5.10 Applicability to Non-Packet Technologies > > I'd like to see in this section a statement saying that earlier described > FRR does not work well in non-packet environments and other techniques > should be considered for inter-domain service recovery. One of such > techniques is the segment recovery, which IMHO works equally well in packet > and non-packet environments > > > > Igor > > ----- Original Message ----- > From: "Kireeti Kompella" > To: > Sent: Tuesday, May 24, 2005 4:49 PM > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > > > >>Hi All, >> >>This starts a two week CCAMP WG Last call on: >>draft-ietf-ccamp-inter-domain-framework-02.txt >> >>Please send your comments to the list (preferably) or to the authors >>latest by June 7, 23:59 GMT. >> >>Thanks, >>Kireeti. >>------- >> >>---------- Forwarded message ---------- >>Date: Mon, 23 May 2005 15:39:15 -0400 >>From: Internet-Drafts@ietf.org >>To: i-d-announce@ietf.org >>Cc: ccamp@ops.ietf.org >>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt >> >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > >>Title : A Framework for Inter-Domain MPLS Traffic Engineering >>Author(s) : A. Farrel, et al. >>Filename : draft-ietf-ccamp-inter-domain-framework-02.txt >>Pages : 19 >>Date : 2005-5-23 >> > > > > > . > From GerardoCarmichael@corneous.com Sun May 29 12:24:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24608 for ; Sun, 29 May 2005 12:24:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcQu3-00007K-55 for ccamp-archive@ietf.org; Sun, 29 May 2005 12:44:44 -0400 Received: from [220.88.102.236] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DcQal-0005bb-Vv for ccamp-archive@ietf.org; Sun, 29 May 2005 12:24:48 -0400 Received: from MLC@localhost by 8mL.int (8.11.6/8.11.6); Sun, 29 May 2005 16:13:35 -0100 Message-ID: From: "Aurelia Singer" Reply-To: "Aurelia Singer" To: ccamp-archive@ietf.org Subject: Windows XP Pro $49.95 Win XP Date: Sun, 29 May 2005 13:11:35 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GerardoCarmichael@corneous.com Content-Type: multipart/mixed; boundary="--HzL55TiqOiIYCcXRXc09" X-Spam-Score: 3.5 (+++) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Xs8 ----HzL55TiqOiIYCcXRXc09 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Z
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH
<= /table>

<= font size=3D1> =

TOP 10 NEW TITLES

<= img src=3Dhttp://g-images.amazon.com/images/G/01/icons/eyebrow-upper-right= -corner.gif width=3D5 height=3D5>
 <= /tr>

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
 4 Norton Antivirus 2005
 5 Flash MX 2004
 6<= /td> Corel Draw 12
7= Adobe Acrobat 7.0
 8 <= a href=3Dhttp://experienceware.net/?o>Windows 2003 Server
 9 Alias Maya 6 Wavefrt<= /td>
 10 Adobe Premiere
  See more by this manufact= urer
   Microsoft
   Apple Software
  Customers also bought
   these other items...



Microsoft = Office Professional Edition *2003*
Microsoft
Choose:
 
List Price:= $899.00
Price:$69.99
You Save:$830.01 (92%)


=
Availability: Available for INSTANT download!
Coupon Co= de: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories&nbs= p; |  Other Versions

Features:

    =
  • Analyze and manage business information u= sing Access databases
  • Exchan= ge data with other systems using enhanced XML technology
  • Control information sharing rules with enhanc= ed IRM technology
  • Easy-to-us= e wizards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted busin= ess reports
Sales Rank:= #1
Shipping: International/US or via instant down= load
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. = Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
&= nbsp;

<= /a>

List Price:$279.00
Price:$49.99<= /b>
You Save:$229.01 (85= %)



Availability:<= /b> Available for INSTANT download!
Coupon Code: ISe229
= Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more=
  • More security with the abil= ity to encrypt files and folders
  • Built-in voice, video, and instant messaging support
    • Integration with Windows servers and managem= ent solutions

Sales Rank: #2=
Shipping: International/US or via instant downloa= d
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
Ch= oose:
 

= =

$529.01 (90= %)
List Price: $599.00
Price:$69.99 =
You Save:



Availability:<= /b> Available for INSTANT download!
Coupon Code: ISe229
= Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review= .

----HzL55TiqOiIYCcXRXc09-- From VivianBronstein@worrywarts.net Sun May 29 17:18:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24983 for ; Sun, 29 May 2005 17:18:37 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcVUQ-0007dB-BH for ccamp-archive@ietf.org; Sun, 29 May 2005 17:38:34 -0400 Received: from cpe-66-25-47-168.houston.res.rr.com ([66.25.47.168]) by mx2.foretec.com with smtp (Exim 4.24) id 1DcVB1-000279-1D for ccamp-archive@ietf.org; Sun, 29 May 2005 17:18:31 -0400 Received: from VbR@localhost by StB.int (8.11.6/8.11.6); Sun, 29 May 2005 15:18:46 -0700 Message-ID: From: "Kate Proctor" Reply-To: "Kate Proctor" To: ccamp-archive@ietf.org Subject: Thousands of academic software titles, 80% off, Instant Download Date: Sun, 29 May 2005 20:22:46 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: VivianBronstein@worrywarts.net Content-Type: multipart/mixed; boundary="--ER4ll9EgxCXBa54Ancq" X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 M1F ----ER4ll9EgxCXBa54Ancq Content-Type: text/html; Content-Transfer-Encoding: quoted-printable k
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= td class=3Dsmall align=3Dmiddle bgColor=3D#ffffdd width=3D707>
=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=

 = ON SALE NOW!

 1 Offi= ce Pro 2003
 2 Windows XP= Pro
 3 Adobe Creative S= uite Premium
 4 Norton An= tivirus 2005
 5 Flash MX = 2004
 6 Corel Draw 12
 7 Adobe Acrobat= 7.0
 8 Windows 2003 Ser= ver
 9 Alias Maya 6 Wave= frt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   Apple Software
  Customers also bought
   these other ite= ms...



Microsoft Office Professional Editi= on *2003*
Micro= soft
Choose:
 
 List Price:$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!
<= b>Coupon Code: ISe229
Media: CD-ROM / Download
<= br> System requirements=   |  Accessories  |&= nbsp; Other Versions

Features:

  • Analyze and manage business information using Access d= atabases
  • Exchange data with = other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM techno= logy
  • Easy-to-use wizards to = create e-mail newsletters and printed marketing materials
    • More than 20 preformatted business reports <= /font>
Sales Rank: #1
Shipping: International/US or via instant download
D= ate Coupon Expires: June 30th, 2005
A= verage Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Wind= ows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)


Availability: Available for INSTANT download!
Coupon Code:= ISe229
Media: CD-ROM / Download

System requirements  |&n= bsp; Accessories  |  Other Versions

Fea= tures:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability t= o encrypt files and folders
  • = Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management s= olutions

Sales Rank: #2
= Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop= CS2 V 9.0
Adob= e
Choose:
 

List Pri= ce: $599.00
Pric= e:$69.99
You Save:<= span class=3Dprice>$529.01 (90%)


=
Availability: Available for INSTANT download!
Coupon Co= de: ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.

= ----ER4ll9EgxCXBa54Ancq-- From owner-ccamp@ops.ietf.org Mon May 30 08:45:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11727 for ; Mon, 30 May 2005 08:45:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcjxF-0008By-0Y for ccamp-archive@ietf.org; Mon, 30 May 2005 09:05:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcjSP-000NJh-8a for ccamp-data@psg.com; Mon, 30 May 2005 12:33:25 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcjSL-000NJP-Sc for ccamp@ops.ietf.org; Mon, 30 May 2005 12:33:22 +0000 Received: from ib (vpn10.atlanta.movaz.com [172.18.0.10]) by jera.movaz.com (Postfix) with SMTP id E8840F77; Mon, 30 May 2005 08:33:17 -0400 (EDT) Message-ID: <00a101c56513$c102fe30$6501a8c0@movaz.com> From: "Igor Bryskin" To: , Cc: "Kireeti Kompella" , References: <20050524134652.P88814@kummer.juniper.net> <008201c562e5$b6329bd0$6501a8c0@movaz.com> <42997530.2090802@psg.com> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Mon, 30 May 2005 08:33:15 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit Dimitri, see in-line. ----- Original Message ----- From: "dimitri papadimitriou" To: "Igor Bryskin" Cc: "Kireeti Kompella" ; Sent: Sunday, May 29, 2005 3:54 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > > > Igor Bryskin wrote: > > Hi, > > > > I have several comments on the document. > > > > Section 1.1 Nested domains: > > > > For further consideration of nested domains see [MRN] > > > > MRN does not cover nested domains, ITU hierarchical routing does. This is a > > hole in (G)MPLS TE > > not sure to understand your comment here, in particular when considering > "switching capability domains" - i suggest you take a look for instance > at section 5.1.7 of MRN that provides you an example if this can help > understanding > IB>> I think we have a problem with the definition of a nested routing domain and this draft is actually a good place to provide such definition. Here is from MRN 5.17: In calculating the path for the PSC-LSP, the TE database is filtered to include the link, both ends of which include only PSC. In this way hierarchical routing of the PSC- LSP and TDM-LSP is done by using a TE database filtered with respect to switching capability. The hierarchical routing IHMO is not about filtering TED with respect to switching capability. The computing entitity in the containing domain cannot do this because it has zero or limited TED information about nested domains. In my view nesting of routing domains and nesting of network regions or layers have nothing in common. For example, nesting of routing domains may happen within a single (say, IP or ATM) layer. > > Section 2.1 LSP Nesting > > > > FA and FA-LSP are not accurate terms for describing LSP nesting, which is > > using an LSP created in one network layer as a data link in other layer(s). > > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a TE > > link, the link is not necessarily FA, that is, it may require direct IGP > > adjacency between its ends to provide necessary control plane connectivity. > > note: a hierarchical LSP does also translate as (using your words) "LSP > created in one network layer as a data link in other layer(s)" the whole > discussion point here is about the control plane instance and > relationship - > IB>> Despite that you quote my own words I have no idea what you just said :=) I just want to remind you that in Minneappolis we had a lengthy discussion (you and Arthi took part in it as well as the authors of LSP-HIER Yakov and Kireeti) about FA and hierarchical LSPs. We all seemed to agree that Forwarding Adjacency (FA) is unfortunately confusing name for a TE link that does not require direct IGP adjacency between its ends for control plane connectivity, that, although H-LSPs and FAs often come together, they do not have to relate to each other. The results of this discussionis are reflected in www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt , section 3.9 > > Thus, the abstract: > > > > Note also that the IGP/EGP routing topology is maintained unaffected by > > the LSP connectivity and TE links introduced by FA LSPs. That is, the > > routing protocols do not exchange messages over the FA LSPs, and such LSPs > > do not create routing adjacencies between routers. is not correct in the > > case when an H-LSP created in one domain is advertised as a TE link into a > > different domain > > so, the document is consistent from that perspective, FAs are not used > for exchanging routing informations - but the previous paragraph must be > reflect this since it makes use of the term "hierarchical LSP" IB>> See above > > Section 2.3 LSP stitching > > > > Again, a stitching segment created in one domain and advertised as a TE link > > into a different domain is not an FA, it is just a "regular" TE link not > > distinguishable from a TE link supported by static data link(s) > > indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." > - but not for the reason you have indicated - simply because there is no > notion of nesting when considering an LSP segment IB>> And I repeat again that FA has nothing to do with the nesting Igor > > > Section 3.3 Domain Boundary Computation > > > > I'd like to see a clause here stating about necessity of avoiding loops with > > the LSP head segment during domain boundary path computation and describing > > some mechanisms how this could be achieved. > > > > Section 5.10 Applicability to Non-Packet Technologies > > > > I'd like to see in this section a statement saying that earlier described > > FRR does not work well in non-packet environments and other techniques > > should be considered for inter-domain service recovery. One of such > > techniques is the segment recovery, which IMHO works equally well in packet > > and non-packet environments > > > > > > > > Igor > > > > ----- Original Message ----- > > From: "Kireeti Kompella" > > To: > > Sent: Tuesday, May 24, 2005 4:49 PM > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > > > > > > > >>Hi All, > >> > >>This starts a two week CCAMP WG Last call on: > >>draft-ietf-ccamp-inter-domain-framework-02.txt > >> > >>Please send your comments to the list (preferably) or to the authors > >>latest by June 7, 23:59 GMT. > >> > >>Thanks, > >>Kireeti. > >>------- > >> > >>---------- Forwarded message ---------- > >>Date: Mon, 23 May 2005 15:39:15 -0400 > >>From: Internet-Drafts@ietf.org > >>To: i-d-announce@ietf.org > >>Cc: ccamp@ops.ietf.org > >>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > >>This draft is a work item of the Common Control and Measurement Plane > > > > Working Group of the IETF. > > > >>Title : A Framework for Inter-Domain MPLS Traffic Engineering > >>Author(s) : A. Farrel, et al. > >>Filename : draft-ietf-ccamp-inter-domain-framework-02.txt > >>Pages : 19 > >>Date : 2005-5-23 > >> > > > > > > > > > > . > > > From owner-ccamp@ops.ietf.org Mon May 30 11:14:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21208 for ; Mon, 30 May 2005 11:14:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcmI9-0002NW-F7 for ccamp-archive@ietf.org; Mon, 30 May 2005 11:35:02 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dclr3-00092X-Oo for ccamp-data@psg.com; Mon, 30 May 2005 15:07:01 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dclr2-000926-6k; Mon, 30 May 2005 15:07:00 +0000 Received: from du-069-0433.access.clara.net ([217.158.145.179] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1Dclqz-000IaA-6e; Mon, 30 May 2005 16:06:59 +0100 Message-ID: <019301c56529$8931e460$23849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , References: <4298ED2B.7010302@psg.com> Subject: Re: comments on draft-ietf-ccamp-inter-domain-framework-02.txt Date: Mon, 30 May 2005 16:03:10 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Content-Transfer-Encoding: 7bit Thanks Dimitri, > some comments on this document: > > 1. introduction refers to a separate document - but without much precision - Hmmm. There is some difficulty in providing a list which will necessarily be assumed to be complete. For the "techniques" (para 3) I propose to add a note to say that references to these documents are given from the sections that discuss the techniques. For the case of GMPLS TE (para 4) I will add a pointer to... [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. > 2. introduction > "However, domains of computational responsibility may also exist as > sub-domains of areas or ASs. Wholly or partially overlapping domains > are not within the scope of this document." > > how the second sentence should be interpreted wrt to the previous one ? OK, this could be clearer. The intention is is to give examples of domains and also not constrain their use. But, we do want to restrict the discussion to non-nested domains at this point. So, computational domains might exist within a single area. The reasons for such domains might be as simple as limited computation power, or limited computation necessity (for example on a subtended ring). Maybe it is OK simply to delete the sentence "However, domains of ...." as this does not add much value. > 3. section 2 refers to > > "Three distinct options for signaling TE LSPs across multiple domains > are identified. The choice of which options to use may be influenced > by the path computation technique used (see section 3), although some > path computation techniques may apply to multiple TE LSP types." > > what are these LSP types ? i think this document is the right place to > disambiguate the signaling methodology from That final "multiple TE LSP types" should read "multiple signaling options" > 4. section 2.1 > > "Furthermore, the mapping (inheritance rules) > between attributes of the nested and FA LSPs (including bandwidth) > may be statically pre-configured or, for on-demand FA LSPs, may be > dynamic according to the properties of the nested LSPs." > > worth indicating here that even in the dynamic case inheritance from the > properties of the nested LSP(s) can be complemented by local or > domain-wide policy rules OK > 5. section 2.1 > > "During the operation of establishing a nested LSP that uses a > hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain > unchanged along the entire length of the nested LSP." the same applies > for the FILTER_SPEC object and any other object that has an end-to-end > significance OK. The point we wanted to make is that the Session remains constant. This seems to be the most important end-to-end property. But I will extend the text to say "and all other objects that have end-to-end significance". > 6. section 2.2 > > this notion of contiguous LSP is unclear, if i correctly understand the > definition i can not establish a contiguous packet LSP using PSC links > that are themselves TDM LSPs - why this restriction ? The notion we are trying to convey is that there is a single LSP established from ingress to egress that does not require the use of FA LSPs or stitching. It is true that you could use hierarchical layered LSPs as you describe, but if you were to expose this fact, you would be using nested domains (which are out of scope). On the other hand, if you hide this fact (by presenting the TDM LSPs as TE links in the PSC domain) then these are just TE links and there is nothing special going on. So... We struggled with the words for section 2.2. Every time we visited the text, we deleted more words. Any suggestions? > 7. section 2.4 > > could be interesting to have better insight on RRO methods to select > signaling method "It may be desirable in this case for the choice of the > various methods to be indicated along the path perhaps through the RRO." The intention was not to use the RRO to select the method, but to report the choice that was made. I have cahnged the text to read... It may be desirable in this case for the choice of the various methods to be reported along the path, perhaps through the RRO. > 8. section 2.5 > > refers to interoperability but in which sense ? object support or > functionality There are two concers as you identify. It is necessary to be backwards compatible. But a greater concern (for me) exists with the creation of too many options: that is, if it is acceptable for LSRs to select which functional components they support, then there is a high risk of "stnadard" implementations not interoperating. I have clarified this in the text. > 9. section 3.2 > > indeed the destination must be provided but i suggest to indicate the > corr. object(s) i.e. Session, ERO subobjects, etc. Ni, I don't think so. The operator does not use Session, ERO or any other objects. The operator simply fills in information in his GUI, CLI or whatever. > 10. section 3.2.1 > > having full visibility provides the capacity to achieve optimality - at > least for a given period of time - in brief, it is not a sufficient > condition OK. "is best" was the wrong choice of words. Changed it to "can be better". > 11. section 3.2.2 > > i guess the proposed formats are not meant to be exchaustive (would be > worth indicating this) Hmmm. I can certainly make the text more ambiguous, but these were the only two formats (apart from the mixed format as indicated) that we could come up with. Do you see any further formats for this mode of visibility? > 12. section 3.3 > > 3rd paragraph is indeed expressing ERO construction per 3209, but then > how to interpreet second bullet of the alternative presented in section > 3.2.2. Don't you just love the ERO processing rules in 3209? :-) Suppose you have an ERO that says, {strict AS A, strict AS B, loose Bn} where Bn is the egress. When we reach A1 in AS A we may *replace* the hop {strict AS A} with the sequence of hops {A2, A3, ...., An}. This is allowed because these hops are all within the abstract node {AS A}. In this sense we are not inserting hops before {strict AS B}. However, when we arrive at An (the border node) the ERO looks like {An, strict AS B, loose Bn}. At this point the abstract node {An} is not open for expansion, and we are not allowed to insert hops before the next hop which is strict, so we must now move on to B1. > 13. section 3.4 > > "The selection of PCE(s) may be driven by static configuration or the > dynamic discovery by means of IGP or BGP extensions." would it be > possible to detail in which context BGP PCE discovery would be > appropriate and the corresponding mechanism applicable I have views on this, but I think the politically correct thing to do here is change the text to read... The selection of PCE(s) may be driven by static configuration or the dynamic discovery. > 14. section 3.4.2 > > paragraph 2 discusses (again) optimality issues but in the context of a > section that speaks about confidentiality - not sure this is the best > place in the document to do so - I guess you are refering to the word "best"? I will delete it as it is superfluous. > 15. section 3.5 > > what is the real purpose of this section ? lot of things is said about > conditions prevailing in multi-domain environments but very few is said > about what could be a baseline on "optimal multi-domain path" - may be > worth considering the last paragraph only - The intention is to point out that optimality by most definitioins is likely to be degraded by the existence of more than one domain (or at least the need to traverse more than one domain). The intention is then to dodge the issue of defining optimality in any generic way. Thus, as you note, there is no baseline for an optimal multi-domain path. We can wordsmith the first paragrpah a bit, I think. > 16. section 4 > > would it be possible to expand on "end-point" reachability information > exchanges - which is at the end the only mandatory information needed > the following "Where any cross-domain reachability and TE information > needs to be advertised, consideration must be given to TE extensions to > BGP, and how these may be fed to the IGPs. ..." is again focusing on TE > info processing I'm not sure I get your point. > 17. section 5.1 > > if this section is dedicated to re-optmization - and considered as an > advanced mechanism - details included as part of section 3.4.2 should be > moved in this section Why? 3.4.2 is talking about normal LSP establishment. I think the confusion comes from the text in 3.4.2 that says... In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute the path on each request or at regular intervals. This should really read as follows... In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute each leg of the path on each request or at regular intervals until requested by the LSRs establishing the LSP. > 18. section 5.1 > > " Note also that where multiple diverse paths are applied end-to-end > (i.e. not simply within protection domains - see section 5.5) the > point of calculation for re-optimization (whether it is PCE, ingress, > or domain entry point) needs to know all such paths before attempting > re-optimization of any one path." > > the notion of diversity is unclear in this sentence i.e. diverse from ? mutually-diverse > 19. section 5.4 > > would it be possible to detail the following sentence, in particular, > when FRR is used in combination with LSP stitching > > "The techniques that must be employed to use Fast Reroute for the > different methods of signaling LSPs identified in section 2 differ > considerably." Hmmm. Our aim here was just to flag that FRR does not simply transport itself to work with hierarchical or stitched LSPs. We wanted to punt on this and make it the responsibility of the applicability I-D or the signaling extensions I-D. I will, however, add a note that... "In particular, there may be issues protecting the ingress and egress LSRs of hierarchical LSPs or stitched segments." > 20. section 5.5 > > would be interesting to know what is meant by "easier" in the following > sentence "The problem is generally considered to be easier and more > efficient when the diverse paths can be computed 'simultaneously' on the > fullest set of information." Replaced with "less complex". > it would also be interesting to know what is meant by "Domain ID" in the > context of the following sentence "The former might be identified using > a combination of domain ID and an SRLG ID that is administered by the > domain." in particular if SRLGs are confined within a domain adding a > domain id to the SRLG ID would only be useful if SRLG id values are not > unique across domains but the latter would then be expected to share > that information - is that the intention ? As you note, this case is intended to apply where the constituents of the SRLG are confined within a domain, but the SRLG is identified with wider scope than the domain. Thus, either we need administration of SRLG IDs across domains (to make the SRLG ID unique across domains) or we need the domain ID to form part of the SRLG identification. > 21. Section 5.8 > > the major issue is whether end-points are supportive of the capability - > this should be highlighted in this section OK > editorial: this document refers to TE LSP and sometimes to LSP is there > any specific different or just a contraction ? i am asking this because > in the context of a document that speaks about Traffic Engineering this > is not necessarily clear Right. I think it is just sloppy editing. The intention is to indicate that we are in the realm of RSVP-TE and not LDP, so all of the LSPs are really TE LSPs. Are there any specific instances of "LSP" which you feel confuse matters? Thanks, Adrian From owner-ccamp@ops.ietf.org Mon May 30 11:14:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21219 for ; Mon, 30 May 2005 11:14:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcmIA-0002Nb-DK for ccamp-archive@ietf.org; Mon, 30 May 2005 11:35:03 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dclr1-000921-GY for ccamp-data@psg.com; Mon, 30 May 2005 15:06:59 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dclr0-00091h-4m; Mon, 30 May 2005 15:06:58 +0000 Received: from du-069-0433.access.clara.net ([217.158.145.179] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1Dclqw-000IaA-6p; Mon, 30 May 2005 16:06:56 +0100 Message-ID: <019201c56529$87723300$23849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Igor Bryskin" Cc: "Kireeti Kompella" , References: <20050524134652.P88814@kummer.juniper.net> <008201c562e5$b6329bd0$6501a8c0@movaz.com> <42997530.2090802@psg.com> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Mon, 30 May 2005 13:52:35 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Hi Igor, Dimitri, > > Section 1.1 Nested domains: > > > > For further consideration of nested domains see [MRN] > > > > MRN does not cover nested domains, ITU hierarchical routing does. > > This is a hole in (G)MPLS TE > > not sure to understand your comment here, in particular when > considering "switching capability domains" - i suggest you take a > look for instance at section 5.1.7 of MRN that provides you an > example if this can help understanding I also don't understand Igor's point. The point about nested domains is that you may represent an entire domain as a node or a link (depending on your favorite aggregation technique) within the nesting domain. Traversing a nested domain is a good candidate for hierarchical LSPs. Multi-region and multi-layer networking are usually associated with nested domains. But this I-D deliberately does not consider domain nesting. It is initially targeted at the TE problems of multi-area and multi-AS while keeping the door open for further developments into multi-layer in the future. Note that although areas are a nested concept, there case of traversing a nested area is limited to disconnections in area 0 and the use of virtual links. So, this I-D is aiming to solve today's problems, and we might well expect future work to examine tomorrow's problems. > > Section 2.1 LSP Nesting > > > > FA and FA-LSP are not accurate terms for describing LSP nesting, > > which is using an LSP created in one network layer as a data link > > in other layer(s). > > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised > > as a TE link, the link is not necessarily FA, that is, it may require > > direct IGP adjacency between its ends to provide necessary control > > plane connectivity. > > note: a hierarchical LSP does also translate as (using your words) "LSP > created in one network layer as a data link in other layer(s)" the whole > discussion point here is about the control plane instance and > relationship - I'm sorry, but Igor seems to be re-defining LSP nesting as "using an LSP created in one network layer as a data link in other layer(s)." There may be some mileage in this by forcing the layering PSC1...PSC4, but this doesn't define nesting. Nesting is the process of carrying one LSP within another. I suggest re-reading section 2.1. It discusses both FAs and hierarchical LSPs, and makes the point that a hierarchical LSP might (or might not) be used as FA LSPs. > > Note also that the IGP/EGP routing topology is maintained > > unaffected by the LSP connectivity and TE links introduced by FA LSPs. > > That is, the routing protocols do not exchange messages over the FA > > LSPs, and such LSPs do not create routing adjacencies between routers. > > is not correct in the case when an H-LSP created in one domain is > > advertised as a TE link into a different domain > > so, the document is consistent from that perspective, FAs are not used > for exchanging routing informations - but the previous paragraph must > be reflect this since it makes use of the term "hierarchical LSP" I am lost! Igor says that the text he quotes is wrong if "FA LSP" is replaced by "H-LSP". But the whole point of the text is that it does not say "H-LSP"! Is there anything wrong with the paragraph as it stands? The previous paragraph, as Dimitri points out, mentions hierarchical LSPs. It says that a hierarchical LSP might or might not be used as an FA LSP, so I don't see what additions or changes are required. If you asking for clarification that it is easy to advertise a hierarchical LSP as a TE link and operate it as a routing adjacency (i.e. set up a virtual link) then that is fine, and I would welcome some proposed text. We should note, however, the considerable dangers of establishing IGP adjacencies across virtual links. On the other hand, I feel that your issues with the use of the term FA are based largely on you thinking in terms of nested domains rather than contiguous domains. > > Section 2.3 LSP stitching > > > > Again, a stitching segment created in one domain and advertised as > > a TE link into a different domain is not an FA, it is just a > > "regular" TE link not distinguishable from a TE link supported by > > static data link(s) > > indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." > - but not for the reason you have indicated - simply because there is > no notion of nesting when considering an LSP segment Consider, please, how stitching is used within the control plane. There is, I contend, no difference between how stitching segments are used and how hierarchical LSPs are used. The difference is entirely in the data plane where, as Dimitri correctly states, there is no notion of nesting. We could go further and point out that for stitching, regardless of the bandwidth actually used, once an end-to-end LSP makes use of a stitching segment, the whole capacity of the corresponding TE link becomes unavailable. I assume that the only sentence in this section that you have issue with is... LSP segments may be managed as FAs and advertised as TE links. Igor says that the a stitching segment created in one domain and advertised as a TE link into a different domain is just a "regular" TE link not distinguishable from a TE link supported by static data links. I agree, and I don't see anything written in the I-D that contradicts this. But, please note (again) that we are not dealing with nested domains. So the question of advertisement from one domain to another is very much moot. I would suggest that the same issues present themselves in stitching as exist in hierarchical LSPs. Do you advertise as a TE link? Do you establish a routing adjacency or just a forwarding adjacency? > > Section 3.3 Domain Boundary Computation > > > > I'd like to see a clause here stating about necessity of avoiding > > loops with the LSP head segment during domain boundary path > > computation and describing some mechanisms how this could be achieved. I think it would be appropriate to highlight the danger of loops in domain boundary computation. We might also note that such dangers only exist in non-linear (i.e. mesh) domain topologies, and even then, only when the domain sequence (expressed as the sequence of domain boundaries) has not been supplied in the ERO. It would not be appropriate to specify solutions in this I-D, but it would be a good idea to suggest the scope of such solutions. Would you like to suggest some text? > > Section 5.10 Applicability to Non-Packet Technologies > > > > I'd like to see in this section a statement saying that earlier > > described FRR does not work well in non-packet environments and > > other techniques should be considered for inter-domain service > > recovery. One of such techniques is the segment recovery, which > > IMHO works equally well in packet and non-packet environments Note that section 5.4 does not endorse FRR. What it says is that FRR exists and works, and must continue to work in the inter-domain case. Further, please note the final paragraph of section 5.4 which seems to say what you want said. I will qualify the definition of FRR in section 5.4 to show that it is for packet-based LSPs. It now reads... MPLS Traffic Engineering Fast Reroute ([FRR]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. In section 5.10 I will add the following paragraph as para 2... On the other hand, some problems such as Fast Re-Route on domain boundaries (see section 5.4) may be handled by the GMPLS technique of segment protection [SEG-PROT] that is applicable to both packet and non-packet switching technologies. Thanks, Adrian From owner-ccamp@ops.ietf.org Mon May 30 11:39:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22767 for ; Mon, 30 May 2005 11:39:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcmfY-0002qK-7m for ccamp-archive@ietf.org; Mon, 30 May 2005 11:59:12 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcmH4-000B52-3B for ccamp-data@psg.com; Mon, 30 May 2005 15:33:54 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcmH2-000B4c-Qs; Mon, 30 May 2005 15:33:53 +0000 Message-ID: <429B3261.4030205@psg.com> Date: Mon, 30 May 2005 17:33:53 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) References: <20050524134652.P88814@kummer.juniper.net> <008201c562e5$b6329bd0$6501a8c0@movaz.com> <42997530.2090802@psg.com> <00a101c56513$c102fe30$6501a8c0@movaz.com> In-Reply-To: <00a101c56513$c102fe30$6501a8c0@movaz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Igor Bryskin wrote: [snip] >>>I have several comments on the document. >>> >>>Section 1.1 Nested domains: >>> >>>For further consideration of nested domains see [MRN] >>> >>>MRN does not cover nested domains, ITU hierarchical routing does. This >>>is a hole in (G)MPLS TE >> >>not sure to understand your comment here, in particular when considering >>"switching capability domains" - i suggest you take a look for instance >>at section 5.1.7 of MRN that provides you an example if this can help >>understanding > > IB>> I think we have a problem with the definition of a nested routing > domain and this draft is actually a good place to provide such definition. > Here is from MRN 5.17: > > In calculating the path for the PSC-LSP, the > TE database is filtered to include the link, both ends of which > include only PSC. In this way hierarchical routing of the PSC- > LSP and TDM-LSP is done by using a TE database filtered with > respect to switching capability. The hierarchical routing IHMO is > not about filtering TED with respect to switching capability. The computing > entitity in the containing domain cannot do this because it has zero or > limited TED information about nested domains. In my view nesting of routing > domains and nesting of network regions or layers have nothing in common. For > example, nesting of routing domains may happen within a single (say, IP or > ATM) layer. i don't think you have quite understood the example in the ref'ed section, now as you are moving the debate to hierarchical routing the response to your question is already detailed in the ason req. document section 4.2 - no need to repeat things all over - >>>Section 2.1 LSP Nesting >>> >>>FA and FA-LSP are not accurate terms for describing LSP nesting, which >>>is using an LSP created in one network layer as a data link in other >>>layer(s). H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a >>>TE link, the link is not necessarily FA, that is, it may require direct IGP >>>adjacency between its ends to provide necessary control plane >>>connectivity. > >>note: a hierarchical LSP does also translate as (using your words) "LSP >>created in one network layer as a data link in other layer(s)" the whole >>discussion point here is about the control plane instance and >>relationship - > > IB>> Despite that you quote my own words I have no idea what you just said > :=) I just want to remind you that in Minneappolis we had a lengthy > discussion (you and Arthi took part in it as well as the authors of LSP-HIER > Yakov and Kireeti) about FA and hierarchical LSPs. We all seemed to agree > that Forwarding Adjacency (FA) is unfortunately confusing name for a TE link > that does not require direct IGP adjacency between its ends for control > plane connectivity, that, although H-LSPs and FAs often come together, they > do not have to relate to each other. The results of this discussionis are > reflected in > www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt > , section 3.9 i am not discussing this i just want to highlight that from a data plane perspective relationship is the same, the section could have been called LSP nesting but introducing the distinction between FA's and non FA's based on the control plane relationship [snip] >>>Section 2.3 LSP stitching >>> >>>Again, a stitching segment created in one domain and advertised as a TE >>>link into a different domain is not an FA, it is just a "regular" TE link not >>>distinguishable from a TE link supported by static data link(s) >> >> indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." >> - but not for the reason you have indicated - simply because there is no >> notion of nesting when considering an LSP segment > > IB>> And I repeat again that FA has nothing to do with the nesting i don't understand your comment the document says "LSP segments MAY be managed as FAs" it could simply add "... or any suitable methods for making these segments usable by nodes not being the head or the tail-end" From owner-ccamp@ops.ietf.org Mon May 30 13:50:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00038 for ; Mon, 30 May 2005 13:50:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcoj0-0005I1-6r for ccamp-archive@ietf.org; Mon, 30 May 2005 14:10:54 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DcoHc-000KSM-Qc for ccamp-data@psg.com; Mon, 30 May 2005 17:42:36 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DcoHZ-000KS1-B1 for ccamp@ops.ietf.org; Mon, 30 May 2005 17:42:33 +0000 Received: from ib (vpn12.atlanta.movaz.com [172.18.0.12]) by jera.movaz.com (Postfix) with SMTP id 03ACE9C94; Mon, 30 May 2005 13:42:29 -0400 (EDT) Message-ID: <002401c5653e$f4239ec0$6501a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" Cc: "Kireeti Kompella" , References: <20050524134652.P88814@kummer.juniper.net> <008201c562e5$b6329bd0$6501a8c0@movaz.com> <42997530.2090802@psg.com> <019201c56529$87723300$23849ed9@Puppy> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Mon, 30 May 2005 13:42:30 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: 7bit Adrian, See my comments in line. ----- Original Message ----- From: "Adrian Farrel" To: "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" ; "Igor Bryskin" Cc: "Kireeti Kompella" ; Sent: Monday, May 30, 2005 8:52 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > Hi Igor, Dimitri, > > > > Section 1.1 Nested domains: > > > > > > For further consideration of nested domains see [MRN] > > > > > > MRN does not cover nested domains, ITU hierarchical routing does. > > > This is a hole in (G)MPLS TE > > > > not sure to understand your comment here, in particular when > > considering "switching capability domains" - i suggest you take a > > look for instance at section 5.1.7 of MRN that provides you an > > example if this can help understanding > > I also don't understand Igor's point. > > The point about nested domains is that you may represent an entire domain > as a node or a link (depending on your favorite aggregation technique) > within the nesting domain. IB>> Not just that. Also an ability to compute path on an entity within containing domain that traverses the nested domain(s) (with no or limited TE visibility) and possibly comes back to the containing domain with full visibility > Traversing a nested domain is a good candidate > for hierarchical LSPs. Multi-region and multi-layer networking are usually > associated with nested domains. IB>> Sorry, this is not true. Nesting of domains can happen within a single layer, like ATM, for example. PNNI handles this because it takes advantage of hierarchical routing, that does not exist in (G-)MPLS TE based on IGP extensions > > But this I-D deliberately does not consider domain nesting. IB>> That is exactly my point - you've got to define or provide a reference to what you explicitly claim you do not consider. So far, you look like using multi-region/multi-layer networking and hierarchical networking interchangably,and I have a problem with that. It is > initially targeted at the TE problems of multi-area and multi-AS while > keeping the door open for further developments into multi-layer in the > future. Note that although areas are a nested concept, there case of > traversing a nested area is limited to disconnections in area 0 and the > use of virtual links. > > So, this I-D is aiming to solve today's problems, and we might well expect > future work to examine tomorrow's problems. > > > > Section 2.1 LSP Nesting > > > > > > FA and FA-LSP are not accurate terms for describing LSP nesting, > > > which is using an LSP created in one network layer as a data link > > > in other layer(s). > > > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised > > > as a TE link, the link is not necessarily FA, that is, it may require > > > direct IGP adjacency between its ends to provide necessary control > > > plane connectivity. > > > > note: a hierarchical LSP does also translate as (using your words) "LSP > > created in one network layer as a data link in other layer(s)" the whole > > discussion point here is about the control plane instance and > > relationship - > > I'm sorry, but Igor seems to be re-defining LSP nesting as "using an LSP > created in one network layer as a data link in other layer(s)." There may > be some mileage in this by forcing the layering PSC1...PSC4, but this > doesn't define nesting. Nesting is the process of carrying one LSP within > another. IB>> Sounds pretty loose to me. Where does this definition come from? What exactly I am re-defining? > > I suggest re-reading section 2.1. It discusses both FAs and hierarchical > LSPs, and makes the point that a hierarchical LSP might (or might not) be > used as FA LSPs. > > > > Note also that the IGP/EGP routing topology is maintained > > > unaffected by the LSP connectivity and TE links introduced by FA LSPs. > > > That is, the routing protocols do not exchange messages over the FA > > > LSPs, and such LSPs do not create routing adjacencies between routers. > > > is not correct in the case when an H-LSP created in one domain is > > > advertised as a TE link into a different domain > > > > so, the document is consistent from that perspective, FAs are not used > > for exchanging routing informations - but the previous paragraph must > > be reflect this since it makes use of the term "hierarchical LSP" > > I am lost! > > Igor says that the text he quotes is wrong if "FA LSP" is replaced by > "H-LSP". IB>>I can see that you are lost completely because I am saying quite opposite. My point is that the word "FA" should not be used in this document at all, it should be replaced with H-LSP or S(stitching)-LSP. This is because it makes little sense to advertise H-LSPs and S-LSPs into the same domain where they were created, and when they are advertised into differnt domains they are not FAs already :=), that is, they require direct IGP peering within the domains they are advertised, hence, they are just "regular" TE links not distinguishable from TE links supported by static links. > But the whole point of the text is that it does not say "H-LSP"! > Is there anything wrong with the paragraph as it stands? > > The previous paragraph, as Dimitri points out, mentions hierarchical LSPs. > It says that a hierarchical LSP might or might not be used as an FA LSP, > so I don't see what additions or changes are required. > > If you asking for clarification that it is easy to advertise a > hierarchical LSP as a TE link and operate it as a routing adjacency (i.e. > set up a virtual link) then that is fine, and I would welcome some > proposed text. We should note, however, the considerable dangers of > establishing IGP adjacencies across virtual links. > > On the other hand, I feel that your issues with the use of the term FA are > based largely on you thinking in terms of nested domains rather than > contiguous domains. IB>> My comments are based on the discussions with the authors of LSP-HIER (Yakov and Kireti) regarding FAs and H-LSPs and I'd appreciate if they correct me if I am wrong, but my understanding is that they interpret the notion FA differently compared how it is used in your document. > > > > Section 2.3 LSP stitching > > > > > > Again, a stitching segment created in one domain and advertised as > > > a TE link into a different domain is not an FA, it is just a > > > "regular" TE link not distinguishable from a TE link supported by > > > static data link(s) > > > > indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." > > - but not for the reason you have indicated - simply because there is > > no notion of nesting when considering an LSP segment > > Consider, please, how stitching is used within the control plane. There > is, I contend, no difference between how stitching segments are used and > how hierarchical LSPs are used. IB>> Agrreed. My point was that none of them are FAs. The difference is entirely in the data > plane where, as Dimitri correctly states, there is no notion of nesting. > We could go further and point out that for stitching, regardless of the > bandwidth actually used, once an end-to-end LSP makes use of a stitching > segment, the whole capacity of the corresponding TE link becomes > unavailable. > > I assume that the only sentence in this section that you have issue with > is... > LSP segments may be managed as FAs and advertised as TE links. > > Igor says that the a stitching segment created in one domain and > advertised as a TE link into a different domain is just a "regular" TE > link not distinguishable from a TE link supported by static data links. I > agree, and I don't see anything written in the I-D that contradicts this. > But, please note (again) that we are not dealing with nested domains. IB>> This is actually has nothing to do with nesting domains. So > the question of advertisement from one domain to another is very much > moot. > > I would suggest that the same issues present themselves in stitching as > exist in hierarchical LSPs. Do you advertise as a TE link? Do you > establish a routing adjacency or just a forwarding adjacency? > > > > Section 3.3 Domain Boundary Computation > > > > > > I'd like to see a clause here stating about necessity of avoiding > > > loops with the LSP head segment during domain boundary path > > > computation and describing some mechanisms how this could be achieved. > > > I think it would be appropriate to highlight the danger of loops in domain > boundary computation. We might also note that such dangers only exist in > non-linear (i.e. mesh) domain topologies, and even then, only when the > domain sequence (expressed as the sequence of domain boundaries) has not > been supplied in the ERO. It would not be appropriate to specify solutions > in this I-D, but it would be a good idea to suggest the scope of such > solutions. > > Would you like to suggest some text? > IB>> Yes, I can do it. Note, that just excluding the RRO of the head segment won't do the job. > > > Section 5.10 Applicability to Non-Packet Technologies > > > > > > I'd like to see in this section a statement saying that earlier > > > described FRR does not work well in non-packet environments and > > > other techniques should be considered for inter-domain service > > > recovery. One of such techniques is the segment recovery, which > > > IMHO works equally well in packet and non-packet environments > > Note that section 5.4 does not endorse FRR. What it says is that FRR > exists and works, and must continue to work in the inter-domain case. > > Further, please note the final paragraph of section 5.4 which seems to > say what you want said. > > I will qualify the definition of FRR in section 5.4 to show that it is > for packet-based LSPs. It now reads... > MPLS Traffic Engineering Fast Reroute ([FRR]) defines local > protection schemes intended to provide fast recovery (in 10s of > msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node > failure. > > In section 5.10 I will add the following paragraph as para 2... > On the other hand, some problems such as Fast Re-Route on domain > boundaries (see section 5.4) may be handled by the GMPLS technique of > segment protection [SEG-PROT] that is applicable to both packet and > non-packet switching technologies. > IB>> Sounds good. > Thanks, > Adrian > From ethan@about.com Mon May 30 18:41:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20030 for ; Mon, 30 May 2005 18:41:36 -0400 (EDT) Received: from [85.137.233.214] (helo=85.137.233.214) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DctGU-0002EP-7O for ccamp-archive@ietf.org; Mon, 30 May 2005 19:01:48 -0400 Message-ID: <532001c56581$2b99ca1a$469cf4ea@about.com> From: "Richard K. Lee" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?SG9ybnkgcGlsbHMgLSAkMi45OS9kb3Nl?= Date: Tue, 31 May 2005 01:39:26 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_250CC570.37EDABA6" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_250CC570.37EDABA6 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_4A937C86.C95EEB98" ------=_NextPart_001_0001_4A937C86.C95EEB98 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Excellent erection Long lasting effects No prescription needed Give it a try! CIALIS - http://www.popularpills.biz/sv/ VIAGRA - http://www.popularpills.biz/vt/ Discreet packaging _________________________________________________________________________ To be taken off future campaigns, go here _________________________________________________________________________ ------=_NextPart_001_0001_4A937C86.C95EEB98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Excellent erection
Long lasting effects
No prescription needed

Give it a try!
CIALIS - http://www.popularpills.biz/sv/
VIAGRA - http://www.popularpills.biz/vt/

Discreet packaging


_________________________________________________________________________
To be taken off future campaigns, go here
_________________________________________________________________________

------=_NextPart_001_0001_4A937C86.C95EEB98-- ------=_NextPart_000_0000_250CC570.37EDABA6-- From TedCrowley@acinformation.co.uk Mon May 30 20:07:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25716 for ; Mon, 30 May 2005 20:07:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcubN-00042Y-H5 for ccamp-archive@ietf.org; Mon, 30 May 2005 20:27:26 -0400 Received: from [221.162.55.193] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DcuHq-0000ip-20 for ccamp-archive@ietf.org; Mon, 30 May 2005 20:07:14 -0400 Received: from SPR@localhost by H1g.int (8.11.6/8.11.6); Tue, 31 May 2005 03:11:30 -0400 Message-ID: <2IBcm8ghMbjs7InTBT40619@cappy.net> From: "Earlene Phillips" Reply-To: "Earlene Phillips" To: casandra.craig@ietf.org Subject: 0nline software, Download Macromedia, Adobe, Windows & others Instantly Date: Tue, 31 May 2005 04:18:30 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: TedCrowley@acinformation.co.uk Content-Type: multipart/mixed; boundary="--KW7TJkTfNTg0sbvUJeH" X-Spam-Score: 5.8 (+++++) X-Spam-Flag: YES X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 YOvJ ----KW7TJkTfNTg0sbvUJeH Content-Type: text/html; Content-Transfer-Encoding: quoted-printable N
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

<= td width=3D4>  Microsoft=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
&nbs= p;4 Norton Antivirus 2005
 5 Flash MX 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
10 Adobe Premiere
 = See more by this manufacturer=
  
&= nbsp;  Apple Software
  Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
<= td vAlign=3Dtop noWrap>
Choose:
<= tr>
 
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Featur= es:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems u= sing enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
  • = More than 20 preformatted business reports
    • Sales Rank: #1
    Ship= ping: International/US or via instant download
    Date Coupon Expi= res: June 30th, 2005
    Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
    <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
    Microsoft Windows XP= Professional or Longhorn Edition
    Microsoft
    Choose:
     

    <= a href=3Dhttp://expansionsoft.com/?D>

    $279.00
    Price:$49.99
    You Save= :$229.01 (85%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Acces= sories  |  Other Versi= ons

    Features:=

    • Designed for businesses o= f all sizes
    • Manage digital p= ictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and folders
    • Built-in voice, video, and insta= nt messaging support
    • Integra= tion with Windows servers and management solutions

    Sales Rank: #2
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    Choose:
     

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

    <= p>Features:

      Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
    • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
    • Create or modify ph= otos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping:= International/US or via instant download
    Date Coupon Expires:<= /b> June 30th, 2005
    Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

----KW7TJkTfNTg0sbvUJeH-- From info@mail.jabujabu.net Tue May 31 09:10:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07545 for ; Tue, 31 May 2005 09:10:03 -0400 (EDT) Received: from [218.187.44.155] (helo=mail.jabujabu.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dd6p2-0002AI-B1 for ccamp-archive@ietf.org; Tue, 31 May 2005 09:30:22 -0400 Received: (qmail 7552 invoked by uid 510); 31 May 2005 16:05:17 +0900 Date: 31 May 2005 16:05:17 +0900 Message-ID: <20050531070517.7550.qmail@mail.jabujabu.net> From: info@jabujabu.net To: ccamp-archive@ietf.org Subject: Re:社長から・・・ X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 　貴方の宛先に社長(女性)からのご指名が有ったことのお知ら せです。個人情報を見て連絡して欲しいとの事です。 ※下記情報は恵子社長の依頼で添付された物ですので、当サイト のスタッフは手を加えておりません。 トップ： http://www.jumpb3.net/?mail ========================================================= 　　　Name　　　恵子 　　　Age　　　 35歳(6月生まれ) 　　　趣味　　　お酒＆ゴルフ ID 105952 伝言メモ： 　　仕事柄、男性は沢山見ていますが、私自身のポリシーと 　して社員とは男女の関係にならないと決めています。した 　がって、毎日全国各地を飛び歩いている私の場合、普通の 　男性とめぐり合う機会が全く無く、知人の紹介でこちらに 　お世話になる事にしました。 　　恋人として付き合う余力があんまりないんで、割切って 　お付き合いできるなら、お住まいの場所まで行ってもいい 　かなぁ〜っと思います。感謝代は当然のことなので、遠慮 　なく言ってくださいね。 　　私は業者ではないので、もし興味がなかったら、私のこ 　とは忘れてくださいね〜さよなら＿〆（・_・、）♪ ========================================================= 無料登録後の返信はコチラ>>> http://www.jumpb3.net/?docomo 　 　　　　　　只今★♪1周年企画期間♪★ 　　登録者※全員※→→\3,000円分ポイント　完全無料　！！ From owner-ccamp@ops.ietf.org Tue May 31 09:56:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10769 for ; Tue, 31 May 2005 09:56:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd7XV-000319-R6 for ccamp-archive@ietf.org; Tue, 31 May 2005 10:16:18 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dd73Y-000OAL-Ij for ccamp-data@psg.com; Tue, 31 May 2005 13:45:20 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dd73W-000OA2-4u for ccamp@ops.ietf.org; Tue, 31 May 2005 13:45:18 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j4VDj94F022344 for ; Tue, 31 May 2005 14:45:10 +0100 (envelope-from Diego.Caviglia@Marconi.com) Subject: LCAS and GMPLS To: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Tue, 31 May 2005 15:45:11 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 31/05/2005 14:45:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi all, I'd like to ask what is the statuts of the interworking between LCAS and GMPLS. Surfing the net I've found a couple of ID about that subject (draft-kim-ccamp-intercaction-grsvpte-lcas and draft-mannie-ccamp-gmpls-tdm-lbm) but both of them seems to be expired, I've also found some interesting discussion on this matter on the ccamp mail archive. Is interwoking between LCAS and GMPLS outside the scope of CCAMP? IMHO that is not and should be addressed. What is the feeling of the rest of the group? Best regards Diego From owner-ccamp@ops.ietf.org Tue May 31 20:49:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14238 for ; Tue, 31 May 2005 20:49:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdHk2-000057-Fv for ccamp-archive@ietf.org; Tue, 31 May 2005 21:10:00 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdHIH-000HdB-NX for ccamp-data@psg.com; Wed, 01 Jun 2005 00:41:13 +0000 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DdHIE-000Hck-O7 for ccamp@ops.ietf.org; Wed, 01 Jun 2005 00:41:10 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j510euwi004434; Tue, 31 May 2005 17:40:56 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j510epCe004397; Tue, 31 May 2005 17:40:51 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.2/8.13.2) with ESMTP id j510enYH020228; Tue, 31 May 2005 17:40:50 -0700 (PDT) Received: from PHOENIX (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id j510egT21562; Tue, 31 May 2005 17:40:42 -0700 (PDT) From: "Richard Rabbat" To: "'Diego Caviglia'" , "'\"\"'ccamp'\" Cc: , "'\"\"'Kohei Shiomoto'\" , "'\"\"'Rajiv Papneja'\" Subject: RE: Addressing doc Date: Tue, 31 May 2005 17:38:08 -0700 Message-ID: <00e301c56642$3282ba30$3e3ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01C56607.8623E230" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.9 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 This is a multi-part message in MIME format. ------=_NextPart_000_00E4_01C56607.8623E230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Diego, =20 We're currently working on an update to draft-ietf-ccamp-gmpls-addressing-00.txt. I was wondering if you have = any ideas w/r to your request below? Are you looking for an explanation of = how LMP could be used or simple text that highlights that LMP is one of the protocols that could be used to do address translation between TE links = and control plane addresses? =20 Richard. =20 -----Original Message----- From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]=20 Sent: Wednesday, April 27, 2005 8:42 AM To: richard.rabbat@us.fujitsu.com Cc: ""'ccamp'" =20 cc: "'Kohei Shiomoto'" , "'Richard Rabbat'" , "'Rajiv Papneja'" =20 Subject: RE: Addressing doc=20 Hi all,=20 =20 The editors have been having various discussions with people about some oftheir issues with this draft. In order to clarify a some points here = are some of thechanges that we plan tomake to the next version of the = draft. We hope thiswill help to clarify the draft.=20 =20 1. In section 4.2.1, previous text:=20 Alternatively, the tunnel end point address MAY also be set to the destination data plane address if the ingress knows that address or the = TE Router ID.=20 New text:=20 Alternatively, the tunnel end point address MAY also be set to thedestination data plane address if the ingress knows that address.=20 =20 2. In section 4.2.2 previous text:=20 Alternatively, the tunnel sender address MAY also be set to = thesender data plane address or the TE Router ID.=20 New text:=20 Alternatively, the tunnel sender address MAY also be set to = thesender data plane address.=20 =20 3. at the end of the introduction, we will add wording to the last line = to that effect:=20 Various more complex deployment scenarios can be constructed but these = are currently out of scope as the only GMPLS implementations encountered ininteroperability testing or in deployment have applied this = relationship. Whennew implementations that include any other relationship between controlplane and data plane entities are encountered, this document = would beenhanced as necessary.=20 ------=_NextPart_000_00E4_01C56607.8623E230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Diego,
 
We're=20 currently working on an update to = draft-ietf-ccamp-gmpls-addressing-00.txt. I=20 was wondering if you have any ideas w/r to your request below? Are you = looking=20 for an explanation of how LMP could be used or simple text that = highlights that=20 LMP is one of the protocols that could be used to do address translation = between=20 TE links and control plane addresses?
 
Richard.
 
-----Original Message-----
From: = Diego Caviglia=20 [mailto:Diego.Caviglia@marconi.com]
Sent: Wednesday, April = 27, 2005=20 8:42 AM
To: richard.rabbat@us.fujitsu.com
Cc: = ""'ccamp'"=20 <ccamp"; ""'Kohei Shiomoto'" <shiomoto.kohei"; ""'Rajiv = Papneja'"=20 <rpapneja"
Subject: RE: Addressing=20 doc


Richiard,=20
        =    =20          IMHO also a section (or sub-section) = dedicated to LMP usage could be very useful in order to clarify how = LMP can=20 help in addressing resolution.

BR

D =

Sent by:   =    =20  owner-ccamp@ops.ietf.org=20

To:     =  =20  "'ccamp'"=20 <ccamp@ops.ietf.org>
cc:        "'Kohei Shiomoto'" <shiomoto.kohei@lab.ntt.co.jp>, = "'Richard=20 Rabbat'" <richard.rabbat@us.fujitsu.com>, "'Rajiv Papneja'"=20 <rpapneja@isocore.com>=20

Subject:  =20      RE: = Addressing=20 doc



Hi all,=20
 
The editors have been having various discussions  with = people=20 about some oftheir issues  with this draft. In order to = clarify a=20 some  points here are some of thechanges that  we plan = tomake to the=20 next version  of the draft. We hope thiswill help =  to clarify=20 the draft.
  =
1. In section 4.2.1,  previous = text:=20
   Alternatively, the = tunnel end=20 point  address MAY also be set to the destination data plane = address=20 if the  ingress knows that address or the TE Router ID. =
New  text:
   Alternatively, the tunnel end point address MAY =  also=20 be set to thedestination data plane  address if the ingress knows = that=20 address.
  =
2. In section 4.2.2 previous = text:=20
   Alternatively, =  the tunnel=20 sender address MAY also be set to thesender data plane address or the = TE=20 Router ID.
New =  text:=20
   Alternatively, the = tunnel sender=20 address MAY also  be set to thesender data plane =  address.=20
 
3. at the end of the introduction, we will add =  wording=20 to the last line to that effect:
Various more complex deployment scenarios can be =  constructed but=20 these are currently out of scope as the only GMPLS = implementations=20 encountered ininteroperability testing or in deployment have =  applied=20 this relationship. Whennew  implementations that include any = other=20 relationship between controlplane and data plane entities are = encountered,=20  this document would beenhanced as  necessary.=20



------=_NextPart_000_00E4_01C56607.8623E230-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 31 May 2005 13:47:36 +0000 Sensitivity: Subject: LCAS and GMPLS To: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Tue, 31 May 2005 15:45:11 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi all, I'd like to ask what is the statuts of the interworking between LCAS and GMPLS. Surfing the net I've found a couple of ID about that subject (draft-kim-ccamp-intercaction-grsvpte-lcas and draft-mannie-ccamp-gmpls-tdm-lbm) but both of them seems to be expired, I've also found some interesting discussion on this matter on the ccamp mail archive. Is interwoking between LCAS and GMPLS outside the scope of CCAMP? IMHO that is not and should be addressed. What is the feeling of the rest of the group? Best regards Diego Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 May 2005 17:44:07 +0000 Message-ID: <002401c5653e$f4239ec0$6501a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" Cc: "Kireeti Kompella" , Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Mon, 30 May 2005 13:42:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, See my comments in line. ----- Original Message ----- From: "Adrian Farrel" To: "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" ; "Igor Bryskin" Cc: "Kireeti Kompella" ; Sent: Monday, May 30, 2005 8:52 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > Hi Igor, Dimitri, > > > > Section 1.1 Nested domains: > > > > > > For further consideration of nested domains see [MRN] > > > > > > MRN does not cover nested domains, ITU hierarchical routing does. > > > This is a hole in (G)MPLS TE > > > > not sure to understand your comment here, in particular when > > considering "switching capability domains" - i suggest you take a > > look for instance at section 5.1.7 of MRN that provides you an > > example if this can help understanding > > I also don't understand Igor's point. > > The point about nested domains is that you may represent an entire domain > as a node or a link (depending on your favorite aggregation technique) > within the nesting domain. IB>> Not just that. Also an ability to compute path on an entity within containing domain that traverses the nested domain(s) (with no or limited TE visibility) and possibly comes back to the containing domain with full visibility > Traversing a nested domain is a good candidate > for hierarchical LSPs. Multi-region and multi-layer networking are usually > associated with nested domains. IB>> Sorry, this is not true. Nesting of domains can happen within a single layer, like ATM, for example. PNNI handles this because it takes advantage of hierarchical routing, that does not exist in (G-)MPLS TE based on IGP extensions > > But this I-D deliberately does not consider domain nesting. IB>> That is exactly my point - you've got to define or provide a reference to what you explicitly claim you do not consider. So far, you look like using multi-region/multi-layer networking and hierarchical networking interchangably,and I have a problem with that. It is > initially targeted at the TE problems of multi-area and multi-AS while > keeping the door open for further developments into multi-layer in the > future. Note that although areas are a nested concept, there case of > traversing a nested area is limited to disconnections in area 0 and the > use of virtual links. > > So, this I-D is aiming to solve today's problems, and we might well expect > future work to examine tomorrow's problems. > > > > Section 2.1 LSP Nesting > > > > > > FA and FA-LSP are not accurate terms for describing LSP nesting, > > > which is using an LSP created in one network layer as a data link > > > in other layer(s). > > > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised > > > as a TE link, the link is not necessarily FA, that is, it may require > > > direct IGP adjacency between its ends to provide necessary control > > > plane connectivity. > > > > note: a hierarchical LSP does also translate as (using your words) "LSP > > created in one network layer as a data link in other layer(s)" the whole > > discussion point here is about the control plane instance and > > relationship - > > I'm sorry, but Igor seems to be re-defining LSP nesting as "using an LSP > created in one network layer as a data link in other layer(s)." There may > be some mileage in this by forcing the layering PSC1...PSC4, but this > doesn't define nesting. Nesting is the process of carrying one LSP within > another. IB>> Sounds pretty loose to me. Where does this definition come from? What exactly I am re-defining? > > I suggest re-reading section 2.1. It discusses both FAs and hierarchical > LSPs, and makes the point that a hierarchical LSP might (or might not) be > used as FA LSPs. > > > > Note also that the IGP/EGP routing topology is maintained > > > unaffected by the LSP connectivity and TE links introduced by FA LSPs. > > > That is, the routing protocols do not exchange messages over the FA > > > LSPs, and such LSPs do not create routing adjacencies between routers. > > > is not correct in the case when an H-LSP created in one domain is > > > advertised as a TE link into a different domain > > > > so, the document is consistent from that perspective, FAs are not used > > for exchanging routing informations - but the previous paragraph must > > be reflect this since it makes use of the term "hierarchical LSP" > > I am lost! > > Igor says that the text he quotes is wrong if "FA LSP" is replaced by > "H-LSP". IB>>I can see that you are lost completely because I am saying quite opposite. My point is that the word "FA" should not be used in this document at all, it should be replaced with H-LSP or S(stitching)-LSP. This is because it makes little sense to advertise H-LSPs and S-LSPs into the same domain where they were created, and when they are advertised into differnt domains they are not FAs already :=), that is, they require direct IGP peering within the domains they are advertised, hence, they are just "regular" TE links not distinguishable from TE links supported by static links. > But the whole point of the text is that it does not say "H-LSP"! > Is there anything wrong with the paragraph as it stands? > > The previous paragraph, as Dimitri points out, mentions hierarchical LSPs. > It says that a hierarchical LSP might or might not be used as an FA LSP, > so I don't see what additions or changes are required. > > If you asking for clarification that it is easy to advertise a > hierarchical LSP as a TE link and operate it as a routing adjacency (i.e. > set up a virtual link) then that is fine, and I would welcome some > proposed text. We should note, however, the considerable dangers of > establishing IGP adjacencies across virtual links. > > On the other hand, I feel that your issues with the use of the term FA are > based largely on you thinking in terms of nested domains rather than > contiguous domains. IB>> My comments are based on the discussions with the authors of LSP-HIER (Yakov and Kireti) regarding FAs and H-LSPs and I'd appreciate if they correct me if I am wrong, but my understanding is that they interpret the notion FA differently compared how it is used in your document. > > > > Section 2.3 LSP stitching > > > > > > Again, a stitching segment created in one domain and advertised as > > > a TE link into a different domain is not an FA, it is just a > > > "regular" TE link not distinguishable from a TE link supported by > > > static data link(s) > > > > indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." > > - but not for the reason you have indicated - simply because there is > > no notion of nesting when considering an LSP segment > > Consider, please, how stitching is used within the control plane. There > is, I contend, no difference between how stitching segments are used and > how hierarchical LSPs are used. IB>> Agrreed. My point was that none of them are FAs. The difference is entirely in the data > plane where, as Dimitri correctly states, there is no notion of nesting. > We could go further and point out that for stitching, regardless of the > bandwidth actually used, once an end-to-end LSP makes use of a stitching > segment, the whole capacity of the corresponding TE link becomes > unavailable. > > I assume that the only sentence in this section that you have issue with > is... > LSP segments may be managed as FAs and advertised as TE links. > > Igor says that the a stitching segment created in one domain and > advertised as a TE link into a different domain is just a "regular" TE > link not distinguishable from a TE link supported by static data links. I > agree, and I don't see anything written in the I-D that contradicts this. > But, please note (again) that we are not dealing with nested domains. IB>> This is actually has nothing to do with nesting domains. So > the question of advertisement from one domain to another is very much > moot. > > I would suggest that the same issues present themselves in stitching as > exist in hierarchical LSPs. Do you advertise as a TE link? Do you > establish a routing adjacency or just a forwarding adjacency? > > > > Section 3.3 Domain Boundary Computation > > > > > > I'd like to see a clause here stating about necessity of avoiding > > > loops with the LSP head segment during domain boundary path > > > computation and describing some mechanisms how this could be achieved. > > > I think it would be appropriate to highlight the danger of loops in domain > boundary computation. We might also note that such dangers only exist in > non-linear (i.e. mesh) domain topologies, and even then, only when the > domain sequence (expressed as the sequence of domain boundaries) has not > been supplied in the ERO. It would not be appropriate to specify solutions > in this I-D, but it would be a good idea to suggest the scope of such > solutions. > > Would you like to suggest some text? > IB>> Yes, I can do it. Note, that just excluding the RRO of the head segment won't do the job. > > > Section 5.10 Applicability to Non-Packet Technologies > > > > > > I'd like to see in this section a statement saying that earlier > > > described FRR does not work well in non-packet environments and > > > other techniques should be considered for inter-domain service > > > recovery. One of such techniques is the segment recovery, which > > > IMHO works equally well in packet and non-packet environments > > Note that section 5.4 does not endorse FRR. What it says is that FRR > exists and works, and must continue to work in the inter-domain case. > > Further, please note the final paragraph of section 5.4 which seems to > say what you want said. > > I will qualify the definition of FRR in section 5.4 to show that it is > for packet-based LSPs. It now reads... > MPLS Traffic Engineering Fast Reroute ([FRR]) defines local > protection schemes intended to provide fast recovery (in 10s of > msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node > failure. > > In section 5.10 I will add the following paragraph as para 2... > On the other hand, some problems such as Fast Re-Route on domain > boundaries (see section 5.4) may be handled by the GMPLS technique of > segment protection [SEG-PROT] that is applicable to both packet and > non-packet switching technologies. > IB>> Sounds good. > Thanks, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 May 2005 15:34:15 +0000 Message-ID: <429B3261.4030205@psg.com> Date: Mon, 30 May 2005 17:33:53 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Igor Bryskin wrote: [snip] >>>I have several comments on the document. >>> >>>Section 1.1 Nested domains: >>> >>>For further consideration of nested domains see [MRN] >>> >>>MRN does not cover nested domains, ITU hierarchical routing does. This >>>is a hole in (G)MPLS TE >> >>not sure to understand your comment here, in particular when considering >>"switching capability domains" - i suggest you take a look for instance >>at section 5.1.7 of MRN that provides you an example if this can help >>understanding > > IB>> I think we have a problem with the definition of a nested routing > domain and this draft is actually a good place to provide such definition. > Here is from MRN 5.17: > > In calculating the path for the PSC-LSP, the > TE database is filtered to include the link, both ends of which > include only PSC. In this way hierarchical routing of the PSC- > LSP and TDM-LSP is done by using a TE database filtered with > respect to switching capability. The hierarchical routing IHMO is > not about filtering TED with respect to switching capability. The computing > entitity in the containing domain cannot do this because it has zero or > limited TED information about nested domains. In my view nesting of routing > domains and nesting of network regions or layers have nothing in common. For > example, nesting of routing domains may happen within a single (say, IP or > ATM) layer. i don't think you have quite understood the example in the ref'ed section, now as you are moving the debate to hierarchical routing the response to your question is already detailed in the ason req. document section 4.2 - no need to repeat things all over - >>>Section 2.1 LSP Nesting >>> >>>FA and FA-LSP are not accurate terms for describing LSP nesting, which >>>is using an LSP created in one network layer as a data link in other >>>layer(s). H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a >>>TE link, the link is not necessarily FA, that is, it may require direct IGP >>>adjacency between its ends to provide necessary control plane >>>connectivity. > >>note: a hierarchical LSP does also translate as (using your words) "LSP >>created in one network layer as a data link in other layer(s)" the whole >>discussion point here is about the control plane instance and >>relationship - > > IB>> Despite that you quote my own words I have no idea what you just said > :=) I just want to remind you that in Minneappolis we had a lengthy > discussion (you and Arthi took part in it as well as the authors of LSP-HIER > Yakov and Kireeti) about FA and hierarchical LSPs. We all seemed to agree > that Forwarding Adjacency (FA) is unfortunately confusing name for a TE link > that does not require direct IGP adjacency between its ends for control > plane connectivity, that, although H-LSPs and FAs often come together, they > do not have to relate to each other. The results of this discussionis are > reflected in > www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt > , section 3.9 i am not discussing this i just want to highlight that from a data plane perspective relationship is the same, the section could have been called LSP nesting but introducing the distinction between FA's and non FA's based on the control plane relationship [snip] >>>Section 2.3 LSP stitching >>> >>>Again, a stitching segment created in one domain and advertised as a TE >>>link into a different domain is not an FA, it is just a "regular" TE link not >>>distinguishable from a TE link supported by static data link(s) >> >> indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." >> - but not for the reason you have indicated - simply because there is no >> notion of nesting when considering an LSP segment > > IB>> And I repeat again that FA has nothing to do with the nesting i don't understand your comment the document says "LSP segments MAY be managed as FAs" it could simply add "... or any suitable methods for making these segments usable by nodes not being the head or the tail-end" Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 May 2005 15:08:12 +0000 Message-ID: <019301c56529$8931e460$23849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Re: comments on draft-ietf-ccamp-inter-domain-framework-02.txt Date: Mon, 30 May 2005 16:03:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Dimitri, > some comments on this document: > > 1. introduction refers to a separate document - but without much precision - Hmmm. There is some difficulty in providing a list which will necessarily be assumed to be complete. For the "techniques" (para 3) I propose to add a note to say that references to these documents are given from the sections that discuss the techniques. For the case of GMPLS TE (para 4) I will add a pointer to... [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. > 2. introduction > "However, domains of computational responsibility may also exist as > sub-domains of areas or ASs. Wholly or partially overlapping domains > are not within the scope of this document." > > how the second sentence should be interpreted wrt to the previous one ? OK, this could be clearer. The intention is is to give examples of domains and also not constrain their use. But, we do want to restrict the discussion to non-nested domains at this point. So, computational domains might exist within a single area. The reasons for such domains might be as simple as limited computation power, or limited computation necessity (for example on a subtended ring). Maybe it is OK simply to delete the sentence "However, domains of ...." as this does not add much value. > 3. section 2 refers to > > "Three distinct options for signaling TE LSPs across multiple domains > are identified. The choice of which options to use may be influenced > by the path computation technique used (see section 3), although some > path computation techniques may apply to multiple TE LSP types." > > what are these LSP types ? i think this document is the right place to > disambiguate the signaling methodology from That final "multiple TE LSP types" should read "multiple signaling options" > 4. section 2.1 > > "Furthermore, the mapping (inheritance rules) > between attributes of the nested and FA LSPs (including bandwidth) > may be statically pre-configured or, for on-demand FA LSPs, may be > dynamic according to the properties of the nested LSPs." > > worth indicating here that even in the dynamic case inheritance from the > properties of the nested LSP(s) can be complemented by local or > domain-wide policy rules OK > 5. section 2.1 > > "During the operation of establishing a nested LSP that uses a > hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain > unchanged along the entire length of the nested LSP." the same applies > for the FILTER_SPEC object and any other object that has an end-to-end > significance OK. The point we wanted to make is that the Session remains constant. This seems to be the most important end-to-end property. But I will extend the text to say "and all other objects that have end-to-end significance". > 6. section 2.2 > > this notion of contiguous LSP is unclear, if i correctly understand the > definition i can not establish a contiguous packet LSP using PSC links > that are themselves TDM LSPs - why this restriction ? The notion we are trying to convey is that there is a single LSP established from ingress to egress that does not require the use of FA LSPs or stitching. It is true that you could use hierarchical layered LSPs as you describe, but if you were to expose this fact, you would be using nested domains (which are out of scope). On the other hand, if you hide this fact (by presenting the TDM LSPs as TE links in the PSC domain) then these are just TE links and there is nothing special going on. So... We struggled with the words for section 2.2. Every time we visited the text, we deleted more words. Any suggestions? > 7. section 2.4 > > could be interesting to have better insight on RRO methods to select > signaling method "It may be desirable in this case for the choice of the > various methods to be indicated along the path perhaps through the RRO." The intention was not to use the RRO to select the method, but to report the choice that was made. I have cahnged the text to read... It may be desirable in this case for the choice of the various methods to be reported along the path, perhaps through the RRO. > 8. section 2.5 > > refers to interoperability but in which sense ? object support or > functionality There are two concers as you identify. It is necessary to be backwards compatible. But a greater concern (for me) exists with the creation of too many options: that is, if it is acceptable for LSRs to select which functional components they support, then there is a high risk of "stnadard" implementations not interoperating. I have clarified this in the text. > 9. section 3.2 > > indeed the destination must be provided but i suggest to indicate the > corr. object(s) i.e. Session, ERO subobjects, etc. Ni, I don't think so. The operator does not use Session, ERO or any other objects. The operator simply fills in information in his GUI, CLI or whatever. > 10. section 3.2.1 > > having full visibility provides the capacity to achieve optimality - at > least for a given period of time - in brief, it is not a sufficient > condition OK. "is best" was the wrong choice of words. Changed it to "can be better". > 11. section 3.2.2 > > i guess the proposed formats are not meant to be exchaustive (would be > worth indicating this) Hmmm. I can certainly make the text more ambiguous, but these were the only two formats (apart from the mixed format as indicated) that we could come up with. Do you see any further formats for this mode of visibility? > 12. section 3.3 > > 3rd paragraph is indeed expressing ERO construction per 3209, but then > how to interpreet second bullet of the alternative presented in section > 3.2.2. Don't you just love the ERO processing rules in 3209? :-) Suppose you have an ERO that says, {strict AS A, strict AS B, loose Bn} where Bn is the egress. When we reach A1 in AS A we may *replace* the hop {strict AS A} with the sequence of hops {A2, A3, ...., An}. This is allowed because these hops are all within the abstract node {AS A}. In this sense we are not inserting hops before {strict AS B}. However, when we arrive at An (the border node) the ERO looks like {An, strict AS B, loose Bn}. At this point the abstract node {An} is not open for expansion, and we are not allowed to insert hops before the next hop which is strict, so we must now move on to B1. > 13. section 3.4 > > "The selection of PCE(s) may be driven by static configuration or the > dynamic discovery by means of IGP or BGP extensions." would it be > possible to detail in which context BGP PCE discovery would be > appropriate and the corresponding mechanism applicable I have views on this, but I think the politically correct thing to do here is change the text to read... The selection of PCE(s) may be driven by static configuration or the dynamic discovery. > 14. section 3.4.2 > > paragraph 2 discusses (again) optimality issues but in the context of a > section that speaks about confidentiality - not sure this is the best > place in the document to do so - I guess you are refering to the word "best"? I will delete it as it is superfluous. > 15. section 3.5 > > what is the real purpose of this section ? lot of things is said about > conditions prevailing in multi-domain environments but very few is said > about what could be a baseline on "optimal multi-domain path" - may be > worth considering the last paragraph only - The intention is to point out that optimality by most definitioins is likely to be degraded by the existence of more than one domain (or at least the need to traverse more than one domain). The intention is then to dodge the issue of defining optimality in any generic way. Thus, as you note, there is no baseline for an optimal multi-domain path. We can wordsmith the first paragrpah a bit, I think. > 16. section 4 > > would it be possible to expand on "end-point" reachability information > exchanges - which is at the end the only mandatory information needed > the following "Where any cross-domain reachability and TE information > needs to be advertised, consideration must be given to TE extensions to > BGP, and how these may be fed to the IGPs. ..." is again focusing on TE > info processing I'm not sure I get your point. > 17. section 5.1 > > if this section is dedicated to re-optmization - and considered as an > advanced mechanism - details included as part of section 3.4.2 should be > moved in this section Why? 3.4.2 is talking about normal LSP establishment. I think the confusion comes from the text in 3.4.2 that says... In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute the path on each request or at regular intervals. This should really read as follows... In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute each leg of the path on each request or at regular intervals until requested by the LSRs establishing the LSP. > 18. section 5.1 > > " Note also that where multiple diverse paths are applied end-to-end > (i.e. not simply within protection domains - see section 5.5) the > point of calculation for re-optimization (whether it is PCE, ingress, > or domain entry point) needs to know all such paths before attempting > re-optimization of any one path." > > the notion of diversity is unclear in this sentence i.e. diverse from ? mutually-diverse > 19. section 5.4 > > would it be possible to detail the following sentence, in particular, > when FRR is used in combination with LSP stitching > > "The techniques that must be employed to use Fast Reroute for the > different methods of signaling LSPs identified in section 2 differ > considerably." Hmmm. Our aim here was just to flag that FRR does not simply transport itself to work with hierarchical or stitched LSPs. We wanted to punt on this and make it the responsibility of the applicability I-D or the signaling extensions I-D. I will, however, add a note that... "In particular, there may be issues protecting the ingress and egress LSRs of hierarchical LSPs or stitched segments." > 20. section 5.5 > > would be interesting to know what is meant by "easier" in the following > sentence "The problem is generally considered to be easier and more > efficient when the diverse paths can be computed 'simultaneously' on the > fullest set of information." Replaced with "less complex". > it would also be interesting to know what is meant by "Domain ID" in the > context of the following sentence "The former might be identified using > a combination of domain ID and an SRLG ID that is administered by the > domain." in particular if SRLGs are confined within a domain adding a > domain id to the SRLG ID would only be useful if SRLG id values are not > unique across domains but the latter would then be expected to share > that information - is that the intention ? As you note, this case is intended to apply where the constituents of the SRLG are confined within a domain, but the SRLG is identified with wider scope than the domain. Thus, either we need administration of SRLG IDs across domains (to make the SRLG ID unique across domains) or we need the domain ID to form part of the SRLG identification. > 21. Section 5.8 > > the major issue is whether end-points are supportive of the capability - > this should be highlighted in this section OK > editorial: this document refers to TE LSP and sometimes to LSP is there > any specific different or just a contraction ? i am asking this because > in the context of a document that speaks about Traffic Engineering this > is not necessarily clear Right. I think it is just sloppy editing. The intention is to indicate that we are in the realm of RSVP-TE and not LDP, so all of the LSPs are really TE LSPs. Are there any specific instances of "LSP" which you feel confuse matters? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 May 2005 15:08:04 +0000 Message-ID: <019201c56529$87723300$23849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Igor Bryskin" Cc: "Kireeti Kompella" , Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Mon, 30 May 2005 13:52:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Igor, Dimitri, > > Section 1.1 Nested domains: > > > > For further consideration of nested domains see [MRN] > > > > MRN does not cover nested domains, ITU hierarchical routing does. > > This is a hole in (G)MPLS TE > > not sure to understand your comment here, in particular when > considering "switching capability domains" - i suggest you take a > look for instance at section 5.1.7 of MRN that provides you an > example if this can help understanding I also don't understand Igor's point. The point about nested domains is that you may represent an entire domain as a node or a link (depending on your favorite aggregation technique) within the nesting domain. Traversing a nested domain is a good candidate for hierarchical LSPs. Multi-region and multi-layer networking are usually associated with nested domains. But this I-D deliberately does not consider domain nesting. It is initially targeted at the TE problems of multi-area and multi-AS while keeping the door open for further developments into multi-layer in the future. Note that although areas are a nested concept, there case of traversing a nested area is limited to disconnections in area 0 and the use of virtual links. So, this I-D is aiming to solve today's problems, and we might well expect future work to examine tomorrow's problems. > > Section 2.1 LSP Nesting > > > > FA and FA-LSP are not accurate terms for describing LSP nesting, > > which is using an LSP created in one network layer as a data link > > in other layer(s). > > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised > > as a TE link, the link is not necessarily FA, that is, it may require > > direct IGP adjacency between its ends to provide necessary control > > plane connectivity. > > note: a hierarchical LSP does also translate as (using your words) "LSP > created in one network layer as a data link in other layer(s)" the whole > discussion point here is about the control plane instance and > relationship - I'm sorry, but Igor seems to be re-defining LSP nesting as "using an LSP created in one network layer as a data link in other layer(s)." There may be some mileage in this by forcing the layering PSC1...PSC4, but this doesn't define nesting. Nesting is the process of carrying one LSP within another. I suggest re-reading section 2.1. It discusses both FAs and hierarchical LSPs, and makes the point that a hierarchical LSP might (or might not) be used as FA LSPs. > > Note also that the IGP/EGP routing topology is maintained > > unaffected by the LSP connectivity and TE links introduced by FA LSPs. > > That is, the routing protocols do not exchange messages over the FA > > LSPs, and such LSPs do not create routing adjacencies between routers. > > is not correct in the case when an H-LSP created in one domain is > > advertised as a TE link into a different domain > > so, the document is consistent from that perspective, FAs are not used > for exchanging routing informations - but the previous paragraph must > be reflect this since it makes use of the term "hierarchical LSP" I am lost! Igor says that the text he quotes is wrong if "FA LSP" is replaced by "H-LSP". But the whole point of the text is that it does not say "H-LSP"! Is there anything wrong with the paragraph as it stands? The previous paragraph, as Dimitri points out, mentions hierarchical LSPs. It says that a hierarchical LSP might or might not be used as an FA LSP, so I don't see what additions or changes are required. If you asking for clarification that it is easy to advertise a hierarchical LSP as a TE link and operate it as a routing adjacency (i.e. set up a virtual link) then that is fine, and I would welcome some proposed text. We should note, however, the considerable dangers of establishing IGP adjacencies across virtual links. On the other hand, I feel that your issues with the use of the term FA are based largely on you thinking in terms of nested domains rather than contiguous domains. > > Section 2.3 LSP stitching > > > > Again, a stitching segment created in one domain and advertised as > > a TE link into a different domain is not an FA, it is just a > > "regular" TE link not distinguishable from a TE link supported by > > static data link(s) > > indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." > - but not for the reason you have indicated - simply because there is > no notion of nesting when considering an LSP segment Consider, please, how stitching is used within the control plane. There is, I contend, no difference between how stitching segments are used and how hierarchical LSPs are used. The difference is entirely in the data plane where, as Dimitri correctly states, there is no notion of nesting. We could go further and point out that for stitching, regardless of the bandwidth actually used, once an end-to-end LSP makes use of a stitching segment, the whole capacity of the corresponding TE link becomes unavailable. I assume that the only sentence in this section that you have issue with is... LSP segments may be managed as FAs and advertised as TE links. Igor says that the a stitching segment created in one domain and advertised as a TE link into a different domain is just a "regular" TE link not distinguishable from a TE link supported by static data links. I agree, and I don't see anything written in the I-D that contradicts this. But, please note (again) that we are not dealing with nested domains. So the question of advertisement from one domain to another is very much moot. I would suggest that the same issues present themselves in stitching as exist in hierarchical LSPs. Do you advertise as a TE link? Do you establish a routing adjacency or just a forwarding adjacency? > > Section 3.3 Domain Boundary Computation > > > > I'd like to see a clause here stating about necessity of avoiding > > loops with the LSP head segment during domain boundary path > > computation and describing some mechanisms how this could be achieved. I think it would be appropriate to highlight the danger of loops in domain boundary computation. We might also note that such dangers only exist in non-linear (i.e. mesh) domain topologies, and even then, only when the domain sequence (expressed as the sequence of domain boundaries) has not been supplied in the ERO. It would not be appropriate to specify solutions in this I-D, but it would be a good idea to suggest the scope of such solutions. Would you like to suggest some text? > > Section 5.10 Applicability to Non-Packet Technologies > > > > I'd like to see in this section a statement saying that earlier > > described FRR does not work well in non-packet environments and > > other techniques should be considered for inter-domain service > > recovery. One of such techniques is the segment recovery, which > > IMHO works equally well in packet and non-packet environments Note that section 5.4 does not endorse FRR. What it says is that FRR exists and works, and must continue to work in the inter-domain case. Further, please note the final paragraph of section 5.4 which seems to say what you want said. I will qualify the definition of FRR in section 5.4 to show that it is for packet-based LSPs. It now reads... MPLS Traffic Engineering Fast Reroute ([FRR]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. In section 5.10 I will add the following paragraph as para 2... On the other hand, some problems such as Fast Re-Route on domain boundaries (see section 5.4) may be handled by the GMPLS technique of segment protection [SEG-PROT] that is applicable to both packet and non-packet switching technologies. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 May 2005 12:36:27 +0000 Message-ID: <00a101c56513$c102fe30$6501a8c0@movaz.com> From: "Igor Bryskin" To: , Cc: "Kireeti Kompella" , Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Mon, 30 May 2005 08:33:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dimitri, see in-line. ----- Original Message ----- From: "dimitri papadimitriou" To: "Igor Bryskin" Cc: "Kireeti Kompella" ; Sent: Sunday, May 29, 2005 3:54 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > > > Igor Bryskin wrote: > > Hi, > > > > I have several comments on the document. > > > > Section 1.1 Nested domains: > > > > For further consideration of nested domains see [MRN] > > > > MRN does not cover nested domains, ITU hierarchical routing does. This is a > > hole in (G)MPLS TE > > not sure to understand your comment here, in particular when considering > "switching capability domains" - i suggest you take a look for instance > at section 5.1.7 of MRN that provides you an example if this can help > understanding > IB>> I think we have a problem with the definition of a nested routing domain and this draft is actually a good place to provide such definition. Here is from MRN 5.17: In calculating the path for the PSC-LSP, the TE database is filtered to include the link, both ends of which include only PSC. In this way hierarchical routing of the PSC- LSP and TDM-LSP is done by using a TE database filtered with respect to switching capability. The hierarchical routing IHMO is not about filtering TED with respect to switching capability. The computing entitity in the containing domain cannot do this because it has zero or limited TED information about nested domains. In my view nesting of routing domains and nesting of network regions or layers have nothing in common. For example, nesting of routing domains may happen within a single (say, IP or ATM) layer. > > Section 2.1 LSP Nesting > > > > FA and FA-LSP are not accurate terms for describing LSP nesting, which is > > using an LSP created in one network layer as a data link in other layer(s). > > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a TE > > link, the link is not necessarily FA, that is, it may require direct IGP > > adjacency between its ends to provide necessary control plane connectivity. > > note: a hierarchical LSP does also translate as (using your words) "LSP > created in one network layer as a data link in other layer(s)" the whole > discussion point here is about the control plane instance and > relationship - > IB>> Despite that you quote my own words I have no idea what you just said :=) I just want to remind you that in Minneappolis we had a lengthy discussion (you and Arthi took part in it as well as the authors of LSP-HIER Yakov and Kireeti) about FA and hierarchical LSPs. We all seemed to agree that Forwarding Adjacency (FA) is unfortunately confusing name for a TE link that does not require direct IGP adjacency between its ends for control plane connectivity, that, although H-LSPs and FAs often come together, they do not have to relate to each other. The results of this discussionis are reflected in www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt , section 3.9 > > Thus, the abstract: > > > > Note also that the IGP/EGP routing topology is maintained unaffected by > > the LSP connectivity and TE links introduced by FA LSPs. That is, the > > routing protocols do not exchange messages over the FA LSPs, and such LSPs > > do not create routing adjacencies between routers. is not correct in the > > case when an H-LSP created in one domain is advertised as a TE link into a > > different domain > > so, the document is consistent from that perspective, FAs are not used > for exchanging routing informations - but the previous paragraph must be > reflect this since it makes use of the term "hierarchical LSP" IB>> See above > > Section 2.3 LSP stitching > > > > Again, a stitching segment created in one domain and advertised as a TE link > > into a different domain is not an FA, it is just a "regular" TE link not > > distinguishable from a TE link supported by static data link(s) > > indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." > - but not for the reason you have indicated - simply because there is no > notion of nesting when considering an LSP segment IB>> And I repeat again that FA has nothing to do with the nesting Igor > > > Section 3.3 Domain Boundary Computation > > > > I'd like to see a clause here stating about necessity of avoiding loops with > > the LSP head segment during domain boundary path computation and describing > > some mechanisms how this could be achieved. > > > > Section 5.10 Applicability to Non-Packet Technologies > > > > I'd like to see in this section a statement saying that earlier described > > FRR does not work well in non-packet environments and other techniques > > should be considered for inter-domain service recovery. One of such > > techniques is the segment recovery, which IMHO works equally well in packet > > and non-packet environments > > > > > > > > Igor > > > > ----- Original Message ----- > > From: "Kireeti Kompella" > > To: > > Sent: Tuesday, May 24, 2005 4:49 PM > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > > > > > > > >>Hi All, > >> > >>This starts a two week CCAMP WG Last call on: > >>draft-ietf-ccamp-inter-domain-framework-02.txt > >> > >>Please send your comments to the list (preferably) or to the authors > >>latest by June 7, 23:59 GMT. > >> > >>Thanks, > >>Kireeti. > >>------- > >> > >>---------- Forwarded message ---------- > >>Date: Mon, 23 May 2005 15:39:15 -0400 > >>From: Internet-Drafts@ietf.org > >>To: i-d-announce@ietf.org > >>Cc: ccamp@ops.ietf.org > >>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > >>This draft is a work item of the Common Control and Measurement Plane > > > > Working Group of the IETF. > > > >>Title : A Framework for Inter-Domain MPLS Traffic Engineering > >>Author(s) : A. Farrel, et al. > >>Filename : draft-ietf-ccamp-inter-domain-framework-02.txt > >>Pages : 19 > >>Date : 2005-5-23 > >> > > > > > > > > > > . > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 29 May 2005 07:56:33 +0000 Message-ID: <42997530.2090802@psg.com> Date: Sun, 29 May 2005 09:54:24 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 MIME-Version: 1.0 To: Igor Bryskin CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Igor Bryskin wrote: > Hi, > > I have several comments on the document. > > Section 1.1 Nested domains: > > For further consideration of nested domains see [MRN] > > MRN does not cover nested domains, ITU hierarchical routing does. This is a > hole in (G)MPLS TE not sure to understand your comment here, in particular when considering "switching capability domains" - i suggest you take a look for instance at section 5.1.7 of MRN that provides you an example if this can help understanding > Section 2.1 LSP Nesting > > FA and FA-LSP are not accurate terms for describing LSP nesting, which is > using an LSP created in one network layer as a data link in other layer(s). > H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a TE > link, the link is not necessarily FA, that is, it may require direct IGP > adjacency between its ends to provide necessary control plane connectivity. note: a hierarchical LSP does also translate as (using your words) "LSP created in one network layer as a data link in other layer(s)" the whole discussion point here is about the control plane instance and relationship - > Thus, the abstract: > > Note also that the IGP/EGP routing topology is maintained unaffected by > the LSP connectivity and TE links introduced by FA LSPs. That is, the > routing protocols do not exchange messages over the FA LSPs, and such LSPs > do not create routing adjacencies between routers. is not correct in the > case when an H-LSP created in one domain is advertised as a TE link into a > different domain so, the document is consistent from that perspective, FAs are not used for exchanging routing informations - but the previous paragraph must be reflect this since it makes use of the term "hierarchical LSP" > Section 2.3 LSP stitching > > Again, a stitching segment created in one domain and advertised as a TE link > into a different domain is not an FA, it is just a "regular" TE link not > distinguishable from a TE link supported by static data link(s) indeed this is not an FA (i.e. "LSP segments may be managed as FAs ..." - but not for the reason you have indicated - simply because there is no notion of nesting when considering an LSP segment > Section 3.3 Domain Boundary Computation > > I'd like to see a clause here stating about necessity of avoiding loops with > the LSP head segment during domain boundary path computation and describing > some mechanisms how this could be achieved. > > Section 5.10 Applicability to Non-Packet Technologies > > I'd like to see in this section a statement saying that earlier described > FRR does not work well in non-packet environments and other techniques > should be considered for inter-domain service recovery. One of such > techniques is the segment recovery, which IMHO works equally well in packet > and non-packet environments > > > > Igor > > ----- Original Message ----- > From: "Kireeti Kompella" > To: > Sent: Tuesday, May 24, 2005 4:49 PM > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > > > >>Hi All, >> >>This starts a two week CCAMP WG Last call on: >>draft-ietf-ccamp-inter-domain-framework-02.txt >> >>Please send your comments to the list (preferably) or to the authors >>latest by June 7, 23:59 GMT. >> >>Thanks, >>Kireeti. >>------- >> >>---------- Forwarded message ---------- >>Date: Mon, 23 May 2005 15:39:15 -0400 >>From: Internet-Drafts@ietf.org >>To: i-d-announce@ietf.org >>Cc: ccamp@ops.ietf.org >>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt >> >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > >>Title : A Framework for Inter-Domain MPLS Traffic Engineering >>Author(s) : A. Farrel, et al. >>Filename : draft-ietf-ccamp-inter-domain-framework-02.txt >>Pages : 19 >>Date : 2005-5-23 >> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 28 May 2005 22:16:15 +0000 Message-ID: <4298ED2B.7010302@psg.com> Date: Sun, 29 May 2005 00:14:03 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: comments on draft-ietf-ccamp-inter-domain-framework-02.txt Content-Type: multipart/mixed; boundary="------------050500030200070008040305" This is a multi-part message in MIME format. --------------050500030200070008040305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit some comments on this document: 1. introduction refers to a separate document - but without much precision - 2. introduction "However, domains of computational responsibility may also exist as sub-domains of areas or ASs. Wholly or partially overlapping domains are not within the scope of this document." how the second sentence should be interpreted wrt to the previous one ? 3. section 2 refers to "Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple TE LSP types." what are these LSP types ? i think this document is the right place to disambiguate the signaling methodology from 4. section 2.1 "Furthermore, the mapping (inheritance rules) between attributes of the nested and FA LSPs (including bandwidth) may be statically pre-configured or, for on-demand FA LSPs, may be dynamic according to the properties of the nested LSPs." worth indicating here that even in the dynamic case inheritance from the properties of the nested LSP(s) can be complemented by local or domain-wide policy rules 5. section 2.1 "During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP." the same applies for the FILTER_SPEC object and any other object that has an end-to-end significance 6. section 2.2 this notion of contiguous LSP is unclear, if i correctly understand the definition i can not establish a contiguous packet LSP using PSC links that are themselves TDM LSPs - why this restriction ? 7. section 2.4 could be interesting to have better insight on RRO methods to select signaling method "It may be desirable in this case for the choice of the various methods to be indicated along the path perhaps through the RRO." 8. section 2.5 refers to interoperability but in which sense ? object support or functionality 9. section 3.2 indeed the destination must be provided but i suggest to indicate the corr. object(s) i.e. Session, ERO subobjects, etc. 10. section 3.2.1 having full visibility provides the capacity to achieve optimality - at least for a given period of time - in brief, it is not a sufficient condition 11. section 3.2.2 i guess the proposed formats are not meant to be exchaustive (would be worth indicating this) 12. section 3.3 3rd paragraph is indeed expressing ERO construction per 3209, but then how to interpreet second bullet of the alternative presented in section 3.2.2. 13. section 3.4 "The selection of PCE(s) may be driven by static configuration or the dynamic discovery by means of IGP or BGP extensions." would it be possible to detail in which context BGP PCE discovery would be appropriate and the corresponding mechanism applicable 14. section 3.4.2 paragraph 2 discusses (again) optimality issues but in the context of a section that speaks about confidentiality - not sure this is the best place in the document to do so - 15. section 3.5 what is the real purpose of this section ? lot of things is said about conditions prevailing in multi-domain environments but very few is said about what could be a baseline on "optimal multi-domain path" - may be worth considering the last paragraph only - 16. section 4 would it be possible to expand on "end-point" reachability information exchanges - which is at the end the only mandatory information needed the following "Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to BGP, and how these may be fed to the IGPs. ..." is again focusing on TE info processing 17. section 5.1 if this section is dedicated to re-optmization - and considered as an advanced mechanism - details included as part of section 3.4.2 should be moved in this section 18. section 5.1 " Note also that where multiple diverse paths are applied end-to-end (i.e. not simply within protection domains - see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path." the notion of diversity is unclear in this sentence i.e. diverse from ? 19. section 5.4 would it be possible to detail the following sentence, in particular, when FRR is used in combination with LSP stitching "The techniques that must be employed to use Fast Reroute for the different methods of signaling LSPs identified in section 2 differ considerably." 20. section 5.5 would be interesting to know what is meant by "easier" in the following sentence "The problem is generally considered to be easier and more efficient when the diverse paths can be computed 'simultaneously' on the fullest set of information." it would also be interesting to know what is meant by "Domain ID" in the context of the following sentence "The former might be identified using a combination of domain ID and an SRLG ID that is administered by the domain." in particular if SRLGs are confined within a domain adding a domain id to the SRLG ID would only be useful if SRLG id values are not unique across domains but the latter would then be expected to share that information - is that the intention ? 21. Section 5.8 the major issue is whether end-points are supportive of the capability - this should be highlighted in this section - editorial: this document refers to TE LSP and sometimes to LSP is there any specific different or just a contraction ? i am asking this because in the context of a document that speaks about Traffic Engineering this is not necessarily clear --------------050500030200070008040305 Content-Type: text/plain; name="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt" Network Working Group Adrian Farrel IETF Internet Draft Olddog Consulting Proposed Status: Informational Expires: November 2005 Jean-Philippe Vasseur Cisco Systems, Inc. Arthi Ayyangar Juniper Networks May 2005 A Framework for Inter-Domain MPLS Traffic Engineering draft-ietf-ccamp-inter-domain-framework-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Farrel, Vasseur and Ayyangar Page 1 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 Contents 1. Introduction ............................................... 3 1.1. Nested Domains ......................................... 3 1.2. Conventions used in this document ...................... 4 2. Signaling Options .......................................... 4 2.1. LSP Nesting ............................................ 4 2.2. Contiguous LSP ......................................... 5 2.3. LSP Stitching .......................................... 5 2.4. Hybrid Methods ......................................... 5 2.5. Control of Downstream Choice of Signaling Method ....... 6 3. Path Computation Techniques ................................ 6 3.1. Management Configuration ............................... 6 3.2. Head End Computation ................................... 6 3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.2. Partial Visibility Computation ..................... 7 3.2.3. Local Domain Visibility Computation ................ 7 3.3. Domain Boundary Computation ............................ 8 3.4. Path Computation Element ............................... 8 3.4.1. Multi-Domain Visibility Computation ................ 9 3.4.2. Path Computation Use of PCE When Preserving Confidentiality .................................... 9 3.4.3. Per-Domain Computation Servers ..................... 9 3.5. Optimal Path Computation ............................... 9 4. Distributing Reachability and TE Information .............. 10 5. Comments on Advanced Functions ............................ 11 5.1. LSP Re-Optimization ................................... 11 5.2. LSP Setup Failure ..................................... 12 5.3. LSP Repair ............................................ 12 5.4. Fast Reroute .......................................... 12 5.5. Comments on Path Diversity ............................ 13 5.6. Domain-Specific Constraints ........................... 14 5.7. Policy Control ........................................ 14 5.8. Inter-domain OAM ...................................... 15 5.9. Point-to-Multipoint ................................... 15 5.10. Applicability to Non-Packet Technologies ............. 15 6. Security Considerations ................................... 15 7. IANA Considerations ....................................... 16 8. Acknowledgements .......................................... 16 9. Intellectual Property Considerations ...................... 16 10. Normative References ..................................... 16 11. Informational References ................................. 17 12. Authors' Addresses ....................................... 18 13. Full Copyright Statement ................................. 19 Farrel, Vasseur and Ayyangar Page 2 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 1. Introduction The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and [INTER-AS]. Various proposals have subsequently been made to address some or all of these requirements through extensions to the RSVP-TE and IGP (ISIS, OSPF) protocols and procedures. This document introduces the techniques for establishing TE LSPs across multiple domains. The functional components of these techniques are separated into the mechanisms for discovering reachability and TE information, for computing the paths of LSPs, and for signaling the LSPs. Note that the aim of this document is not to detail each of those techniques which are covered in separate documents, but rather to propose a framework for inter-domain MPLS Traffic Engineering. Note that in the remainder of this document, the term 'MPLS Traffic Engineering' is used equally to apply to MPLS and GMPLS traffic. Specific issues pertaining to the use of GMPLS in inter-domain environments (for example, policy implications of the use of the Link Management Protocol [LMP] on inter-domain links) these are covered in a separate document. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. However, domains of computational responsibility may also exist as sub-domains of areas or ASs. Wholly or partially overlapping domains are not within the scope of this document. 1.1. Nested Domains Nested domains are outside the scope of this document. It may be that some domains that are nested administratively or for the purposes of address space management can be considered as adjacent domains for the purposes of this document, however the fact that the domains are nested is then immaterial. In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is wholly contained in Domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A. For further consideration of nested domains see [MRN] Farrel, Vasseur and Ayyangar Page 3 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Signaling Options Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple TE LSP types. The choice may further depend on the application to which the TE LSPs are put and the nature, topology and switching capabilities of the network. A comparison of the usages of the different signaling options is beyond the scope of this document and should be the subject of a separate applicability statement. 2.1. LSP Nesting Forwarding Adjacencies (FAs) are introduced and explained in detail in [HIER]. No further description is necessary in this document. FAs can be used in support of inter-domain TE LSPs. In particular, an FA may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the FA LSP could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. The technique of carrying one TE LSP within another is termed LSP nesting. An FA may provide a TE LSP tunnel to transport (i.e. nest) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a one-to-one mapping. The signaling trigger for the establishment of an FA LSP may be the receipt of a signaling request for the TE LSP that it will carry, or may be a management action to 'pre-engineer' a domain to be crossed by TE LSPs that would be used as FAs by the traffic that has to traverse the domain. Furthermore, the mapping (inheritance rules) between attributes of the nested and FA LSPs (including bandwidth) may be statically pre-configured or, for on-demand FA LSPs, may be dynamic according to the properties of the nested LSPs. Note that a hierarchical LSP may be constructed to span multiple domains or parts of domains. However, how or whether such an LSP could be advertised as an FA that spans domains is open for study. The end points of a hierarchical LSP are not necessarily on domain boundaries, so nesting is not limited to domain boundaries. Farrel, Vasseur and Ayyangar Page 4 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 Note also that the IGP/EGP routing topology is maintained unaffected by the LSP connectivity and TE links introduced by FA LSPs. That is, the routing protocols do not exchange messages over the FA LSPs, and such LSPs do not create routing adjacencies between routers. During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP. 2.2. Contiguous LSP A single contiguous LSP is established from ingress to egress in a single signaling exchange. No further LSPs are required to be established to support this LSP. Signaling occurs between adjacent neighbors only (no tunneling), and hop-by-hop signaling is used. 2.3. LSP Stitching LSP Stitching is described in [STITCH]. In the LSP stitching model separate LSPs (referred to as a TE LSP segments) are established and are "stitched" together in the data plane so that a single end-to-end label switched path is achieved. The distinction is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination. LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. The signaling trigger for the establishment of a TE LSP segment may be the establishment of the previous TE LSP segment, the receipt of setup request for TE LSP that it plans to stitch to a local TE LSP segment, or may be a management action. LSP segments may be managed as FAs and advertised as TE links. 2.4. Hybrid Methods There is nothing to prevent the mixture of signaling methods described above when establishing a single, end-to-end, inter-domain TE LSP. It may be desirable in this case for the choice of the various methods to be indicated along the path perhaps through the RRO. If there is a desire to restrict which methods are used, this MUST be signaled as described in the next section. Farrel, Vasseur and Ayyangar Page 5 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 2.5. Control of Downstream Choice of Signaling Method Notwithstanding the previous section, an ingress LSR MAY wish to restrict the signaling methods applied to a particular LSP at domain boundaries across the network. Such control, where it is required, may be achieved by the definition of appropriate new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to provide this level of control, the functional requirement to control the way in which the network delivers a service must be established and due consideration must be given to the impact on interoperability. 3. Path Computation Techniques The discussion of path computation techniques within this document is limited significantly to the determination of where computation may take place and what components of the full path may be determined. The techniques used are closely tied to the signaling methodologies described in the previous section in that certain computation techniques may require the use of particular signaling approaches and vice versa. Any discussion of the appropriateness of a particular path computation technique in any given circumstance is beyond the scope of this document and should be described in a separate applicability statement. Path computation algorithms are firmly out of scope of this document. 3.1. Management Configuration Path computation may be performed by offline tools or by a network planner. The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and encoded by the ingress LSR as an ERO on the Path message that is sent out. There is no reason why the path provided by the operator should not span multiple domains if the relevant information is available to the planner or the offline tool. The definition of what information is needed to perform this operation and how that information is gathered, is outside the scope of this document. 3.2. Head End Computation The head end, or ingress, LSR may assume responsibility for path computation when the operator supplies part or none of the explicit path. The operator MUST, in any case, supply at least the destination address (egress) of the LSP. Farrel, Vasseur and Ayyangar Page 6 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 3.2.1. Multi-Domain Visibility Computation If the ingress has sufficient visibility of the topology and TE information for all of the domains across which it will route the LSP to its destination then it may compute and provide the entire path. The quality of this path (that is, its optimality as discussed in section 3.5) is best if the ingress has full visibility into all relevant domains rather than just sufficient visibility to provide some path to the destination. Extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.2. Partial Visibility Computation It may be that the ingress does not have full visibility of the topology of all domains, but does have information about the connectedness of the domains and the TE resource availability across the domains. In this case, the ingress is not able to provide a fully specified strict explicit path from ingress to egress. However, the ingress can supply an explicit path that comprises: - explicit hops from ingress to the local domain boundary - loose hops representing the domain entry points across the network - a loose hop identifying the egress. Alternatively, the explicit path may be expressed as: - explicit hops from ingress to the local domain boundary - strict hops giving abstract nodes representing each domain in turn - a loose hop identifying the egress. These two explicit path formats may be mixed. This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3. As with the multi-domain visibility option, extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.3. Local Domain Visibility Computation A final possibility for ingress-based computation is that the ingress LSR has visibility only within its own domain, and connectivity information only as far as determining one or more domain exit points that may be suitable for carrying the LSP to its egress. In this case the ingress builds an explicit path that comprises just: - explicit hops from ingress to the local domain boundary - a loose hop identifying the egress. Farrel, Vasseur and Ayyangar Page 7 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 3.3. Domain Boundary Computation If the partial explicit path methods described in sections 3.2.2 or 3.2.3 are applied then the LSR at each domain boundary is responsible for ensuring that there is sufficient path information added to the Path message to carry it at least to the next domain boundary (that is, out of the new domain). If the LSR at the domain boundary has full visibility to the egress then it can supply the entire explicit path. Note however, that the ERO processing rules of [RFC3209] state that it SHOULD only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO) and, of course, MUST NOT insert ERO subobjects immediately before a strict hop. If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2) it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO. If the LSR at the domain boundary has only local visibility into the immediate domain it will simply add information to the ERO to carry the Path message as far as the next domain boundary. 3.4. Path Computation Element The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information - see section 4. An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [PCE]. There may be either a centralized PCE, or multiple PCEs (each having local visibility and collaborating in a distributed fashion to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources as would be used by LSRs in the previous paragraph, or though other means. Each LSR called upon to perform path computation (and even the offline management tools described in section 3.1) may abdicate the task to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or the dynamic discovery by means of IGP or BGP extensions. Farrel, Vasseur and Ayyangar Page 8 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 3.4.1. Multi-Domain Visibility Computation A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case it is able to supply a full explicit path as in section 3.2.1. 3.4.2. Path Computation Use of PCE When Preserving Confidentiality Note that although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g to preserve confidentiality) that the full path is not provided to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are required to make further requests for each successive segment of the path. In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute the best path on each request or at regular intervals. It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that normally operational between domains. 3.4.3. Per-Domain Computation Elements A third way that PCEs may be used is simply to have one (or more) per domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE. This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE. 3.5. Optimal Path Computation An optimal route might be defined as the route that would be computed in the absence of domain boundaries. Another constraint to the definition of 'optimal' might be to reduce or limit the number of domains crossed by the LSP. It is easy to construct examples that show that partitioning a network into domains, and the resulting loss or aggregation of routing information may lead to the computation of routes that are other than optimal. It is impossible to guarantee optimal routing in the presence of aggregation / abstraction / summarization of routing information. Farrel, Vasseur and Ayyangar Page 9 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 It is beyond the scope of this document to define what is an optimum path for an inter-domain TE LSP. This debate is abdicated in favor of requirements documents and applicability statements. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6). 4. Distributing Reachability and TE Information Traffic Engineering information is collected into a TE Database (TED) on which path computation algorithms operate either directly or by first constructing a network graph. The path computation techniques described in the previous section make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains. Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784]. In cases where two domains are interconnected by one or more links (that is, the domain boundary falls on a link rather than on a node), there SHOULD be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would facilitate better path computation and reduce TE-related crankbacks on these links. Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way, or two way. Where information needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain. It could be possible that an LSR that performs path computation (for example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to FAs across other domains, or the information may be aggregated or abstracted). Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to BGP, and how these may be fed to the IGPs. Techniques for inter-domain TE aggregation are also for further study. However, it must be noted that any extensions that cause a significant increase in the amount of processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of information flooded (such as detailed TE information) need to be treated with extreme caution Farrel, Vasseur and Ayyangar Page 10 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 and compared carefully with the scaling requirements expressed in [INTER-AREA] and [INTER-AS]. 5. Comments on Advanced Functions This section provides some non-definitive comments on the constraints placed on advanced MPLS TE functions by inter-domain MPLS. It does not attempt to state the implications of using one inter-domain technique or another. Such material is deferred to appropriate applicability statements where statements about the capabilities of existing or future signaling, routing and computation techniques to deliver the functions listed should be made. 5.1. LSP Re-Optimization Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (where no attempt is made in this document to define 'preferable' as no attempt was made to define 'optimal'). Make-before-break techniques are usually applied to ensure that traffic is disrupted as little as possible. The Shared Explicit style is usually used to avoid double booking of network resources. Re-optimization may be available within a single domain. Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains. Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized. The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example bandwidth) of an LSP. This trigger MUST be applied to the point in the network that requests re-computation and controls re-optimization and may require additional signaling. Note also that where multiple diverse paths are applied end-to-end (i.e. not simply within protection domains - see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of Farrel, Vasseur and Ayyangar Page 11 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re-optimization path calculations performed in another domain. 5.2. LSP Setup Failure When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP. In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary. If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error MUST be reported back to the previous or head-end domain. Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of confidentiality although crankback aggregation may be applicable at domain boundaries. Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE]. When requested by signaling, the failure may also be systematically reported to the head-end LSR. 5.3. LSP Repair An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or for handling setup failures (see previous two sections). Fast Reroute may also be used (see below). 5.4. Fast Reroute MPLS Traffic Engineering Fast Reroute ([FRR]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The Farrel, Vasseur and Ayyangar Page 12 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 node immediately upstream of the failure (called the PLR - Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource. In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [FRR] specifies two distinct modes of operation referred to as the "one to one mode" and the "facility back-up mode". The failure scenarios specific to inter-domain TE are as follows: - Failure of a domain edge node that is present in both domains. There are two sub-cases: - The PLR and the MP are in the same domain - The PLR and the MP are in different domains. - Failure of a domain edge node that is only present in one of the domains. - Failure of an inter-domain link. The techniques that must be employed to use Fast Reroute for the different methods of signaling LSPs identified in section 2 differ considerably. These should be explained further in applicability statements of, in the case, of a change in base behavior, in implementation guidelines specific to the signaling techniques. Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re-optimization (for example the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event. It is important to note that Fast Reroute techniques are only applicable to packet switching networks because other network technologies cannot apply label stacking within the same switching type. Segment protection [SEG-PROT] provides a suitable alternative that is applicable to packet and non-packet networks. 5.5. Comments on Path Diversity Diverse paths may be required in support of load sharing and/or protection. Such diverse paths may be required to be node diverse, link diverse, fully path diverse (that is, link and node diverse), or SRLG diverse. Diverse path computation is a classic problem familiar to all graph theory majors. The problem is compounded when there are areas of Farrel, Vasseur and Ayyangar Page 13 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 'private knowledge' such as when domains do not share topology information. The problem is generally considered to be easier and more efficient when the diverse paths can be computed 'simultaneously' on the fullest set of information. That being said, various techniques (out of the scope of this document) exist to ensure end-to-end path diversity across multiple domains. Many network technologies utilize 'protection domains' because they fit well with the capabilities of the technology. As a result, many domains are operated as protection domains. In this model, protection paths converge at domain boundaries. Note that the question of SRLG identification is not yet fully answered. There are two classes of SRLG: - those that indicate resources that are all contained witin one domain - those that span domains. The former might be identified using a combination of domain ID and an SRLG ID that is administered by the domain. The latter requires a wider scope to the SRLG ID, and it is not clear how this would be administered. 5.6. Domain-Specific Constraints While the meaning of certain constraints, like bandwidth, can be assumed to be constant across different domains, other TE constraints (such as resource affinity, color, metric, priority, etc.) may have different meanings in different domains and this may impact the ability to support DiffServ-aware MPLS, or to manage pre-emption. In order to achieve consistent meaning and LSP establishment, this fact must be considered when performing constraint-based path computation or when signaling across domain boundaries. A mapping function can be derived for most constraints based on policy agreements between the Domain administrators. The details of such a mapping function are outside the scope of this document, but it is important to note that the default behavior MUST either be that a constant mapping is applied or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules. 5.7. Policy Control Domain boundaries are natural points for policy control. There is little to add on this subject except to note that a TE LSP that cannot be established on a path through one domain because of a policy applied at the domain boundary, may be satisfactorily Farrel, Vasseur and Ayyangar Page 14 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 established using a path that avoids the demurring domain. In any case, when a TE LSP signaling attempt is rejected due to non-compliance with some policy constraint, this SHOULD be reflected to the ingress LSR. 5.8. Inter-domain OAM Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to-end OAM. The different signaling mechanisms described above may need refinements to [LSPPING], and [BFD-MPLS], etc., to gain full end-to-end visibility. These protocols should, however, be considered in the light of confidentiality requirements. Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for confidentiality or other policy reasons. 5.9. Point-to-Multipoint Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of scope of this document. They may be covered by other documents dependent on the details of MPLS TE P2MP solutions. 5.10. Applicability to Non-Packet Technologies Non-packet switching technologies may present particular issues for inter-domain LSPs. While packet switching networks may utilize control planes built on MPLS or GMPLS technology, non-packet networks are limited to GMPLS. The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS]. 6. Security Considerations Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], but requirements for inter-domain security are, if anything, more significant. Authentication techniques identified for use with RSVP-TE can only operate across domain boundaries if there is coordination between the administrators of those domains. Farrel, Vasseur and Ayyangar Page 15 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 Confidentiality may also be considered to be security factors. Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections. 7. IANA Considerations This document makes no requests for any IANA action. 8. Acknowledgements The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document. Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their review and suggestions on the text. 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Farrel, Vasseur and Ayyangar Page 16 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 11. Informational References [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes, work in progress. [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work in progress. [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", draft-ietf-ccamp-crankback, work in progress. [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, draft-ietf-ccamp-rsvp-te-exclude-route, work in progress. [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, work in progress. [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress. [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-req, work in progress. Farrel, Vasseur and Ayyangar Page 17 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-te-req, work in progress. [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness in MPLS", draft-ietf-mpls-lsp-ping, work in progress. [MRN] K. Shiomoto, et al., "Requirements for GMPLS-based multi-region and multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay, work in progress. [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, A., "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery, work in progress. [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching, work in progress. 12. Authors' Addresses Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Arthi Ayyangar Juniper Networks, Inc 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA Email: arthi@juniper.net Farrel, Vasseur and Ayyangar Page 18 draft-ietf-ccamp-inter-domain-framework-02.txt May 2005 13. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Farrel, Vasseur and Ayyangar Page 19 --------------050500030200070008040305-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 28 May 2005 09:44:21 +0000 Message-ID: <006901c56369$d4fb92e0$23849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "WG Milestone Tracker" Subject: draft-ietf-ccamp-gmpls-segment-recovery-02.txt ready for AD review Date: Sat, 28 May 2005 10:28:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, draft-ietf-ccamp-gmpls-segment-recovery-02.txt is ready for AD review and moving forward through the process as a Standards Track ID. The draft has been through CCAMP working group last call and has been updated to my satisfaction (but please note that I am a co-author). You may wish to handle this I-D together with draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt since they share a new version of the Protection object. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 May 2005 18:00:17 +0000 Message-ID: <008201c562e5$b6329bd0$6501a8c0@movaz.com> From: "Igor Bryskin" To: "Kireeti Kompella" , Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Date: Fri, 27 May 2005 13:58:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have several comments on the document. Section 1.1 Nested domains: For further consideration of nested domains see [MRN] MRN does not cover nested domains, ITU hierarchical routing does. This is a hole in (G)MPLS TE Section 2.1 LSP Nesting FA and FA-LSP are not accurate terms for describing LSP nesting, which is using an LSP created in one network layer as a data link in other layer(s). H-LSP (Hierarchical LSP) is a better term. When H-LSP is advertised as a TE link, the link is not necessarily FA, that is, it may require direct IGP adjacency between its ends to provide necessary control plane connectivity. Thus, the abstract: Note also that the IGP/EGP routing topology is maintained unaffected by the LSP connectivity and TE links introduced by FA LSPs. That is, the routing protocols do not exchange messages over the FA LSPs, and such LSPs do not create routing adjacencies between routers. is not correct in the case when an H-LSP created in one domain is advertised as a TE link into a different domain Section 2.3 LSP stitching Again, a stitching segment created in one domain and advertised as a TE link into a different domain is not an FA, it is just a "regular" TE link not distinguishable from a TE link supported by static data link(s) Section 3.3 Domain Boundary Computation I'd like to see a clause here stating about necessity of avoiding loops with the LSP head segment during domain boundary path computation and describing some mechanisms how this could be achieved. Section 5.10 Applicability to Non-Packet Technologies I'd like to see in this section a statement saying that earlier described FRR does not work well in non-packet environments and other techniques should be considered for inter-domain service recovery. One of such techniques is the segment recovery, which IMHO works equally well in packet and non-packet environments Igor ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Tuesday, May 24, 2005 4:49 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) > Hi All, > > This starts a two week CCAMP WG Last call on: > draft-ietf-ccamp-inter-domain-framework-02.txt > > Please send your comments to the list (preferably) or to the authors > latest by June 7, 23:59 GMT. > > Thanks, > Kireeti. > ------- > > ---------- Forwarded message ---------- > Date: Mon, 23 May 2005 15:39:15 -0400 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: ccamp@ops.ietf.org > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Framework for Inter-Domain MPLS Traffic Engineering > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-inter-domain-framework-02.txt > Pages : 19 > Date : 2005-5-23 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 May 2005 19:47:20 +0000 Message-Id: <200505261945.PAA26881@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-02.txt Date: Thu, 26 May 2005 15:45:53 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Based Segment Recovery Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-gmpls-segment-recovery-02.txt Pages : 24 Date : 2005-5-26 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. This document also updates the handling of Notify_Request objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-segment-recovery-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-26161622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-segment-recovery-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-26161622.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 May 2005 07:25:12 +0000 From: "Adrian Farrel" To: zinin@psg.com Cc: ccamp@ops.ietf.org, iesg-secretary@ietf.org, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: draft-ietf-ccamp-loose-path-reopt-01.txt ready for AD review Date: Thu, 26 May 2005 08:23:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Alex, draft-ietf-ccamp-loose-path-reopt-01.txt is ready for AD review and progress towards being an Informational RFC. It has been through CCAMP working group last call and has been updated to my satisfaction. Note that some IPR issues were raised. After discussion, the I-D has been moved to the Informational track, and a note (section 1) has been added to explain how the procedures are entirely optional. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 May 2005 19:54:44 +0000 Message-Id: <200505251952.PAA15854@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-loose-path-reopt-01.txt Date: Wed, 25 May 2005 15:52:31 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-loose-path-reopt-01.txt Pages : 13 Date : 2005-5-25 This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering LSPs. A loosely routed LSP is defined as one that does not contain a full explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no ERO, with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR). This document proposes a mechanism that allows a TE LSP head-end LSR to trigger a new path re- evaluation on every hop having a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path in use) or that the TE LSP must be reoptimized because of some maintenance required on the TE LSP path. The proposed mechanism applies to the cases of intra and inter-domain (IGP area or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-loose-path-reopt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-25160028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-loose-path-reopt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-25160028.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 May 2005 16:31:21 +0000 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <59d78304545051025d916c06317d0d2a@cisco.com> Content-Transfer-Encoding: 7bit Cc: , "Scott Bradner" , , "Bill Fenner" From: JP Vasseur Subject: Re: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Wed, 25 May 2005 12:30:08 -0400 To: "Adrian Farrel" Hi Adrian, draft-ietf-ccamp-loose-path-reopt has been republished with the agreed changes. Thanks. JP. On May 13, 2005, at 1:18 PM, Adrian Farrel wrote: > JP, > > Thanks for your proposals. > > After consultation, I find that under the new IPR rules we do not make > specific reference to IPR disclosures in I-Ds or RFCs. Instead, the > boilerplate says that there "may be" IPR claims, and refers the reader > to > the Web pages. This is a future-proof technique. > > Therefore, I have tweaked your suggestions below. > >> 1. Text is added to the I-D as follows. >> >> The procedures described in this document are the subject of an >> Intellectual Property Rights claim. For this reason, the procedures >> are >> entirely optional within an MPLS or GMPLS network. Implementations >> that >> do not support the procedures described in this document will >> interoperate seamlessly with those that do. >> Further, an implementation that does not support the procedures >> described in this document will not be impacted or implicated by a >> neighboring implementation that does implement the procedures. > > Replace this paragraph with... > The procedures described in this document are > entirely optional within an MPLS or GMPLS network. Implementations that > do not support the procedures described in this document will > interoperate seamlessly with those that do. > Further, an implementation that does not support the procedures > described in this document will not be impacted or implicated by a > neighboring implementation that does implement the procedures. > >> An ingress implementation that chooses not to support the procedures >> described in this document may still achieve re-optimization by >> periodically issuing a speculative make-before-break replacement of an >> LSP without trying to discovery whether a more optimal path is >> available in a downstream domain. Such a procedure would not be in >> conflict with any mechanisms not already documented in [RFC3209] and >> [RFC3473]. > > Second paragraph is fine. > >> 2. The I-D should be updated with comments arising from the WG last >> call. > > Yes please. > >> 3. The I-D should be progressed as an informational RFC > > Yes. This is advisable. > > Please update the I-D and submit it. I will then forward it to Alex > for AD > review. > > Cheers, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 May 2005 07:05:20 +0000 From: "Adrian Farrel" To: zinin@psg.com Cc: ccamp@ops.ietf.org, iesg-secretary@ietf.org, fenner@research.att.com, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: draft-ietf-ccamp-crankback-05.txt ready for AD review Date: Wed, 25 May 2005 08:03:30 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Hi Alex, draft-ietf-ccamp-crankback-05.txt is ready for AD review and progression through the process. It is targeted at Standards Track. The I-D has been through WG last call and has been liaised to ITU-T SG15. Updates have been made in response to comments made in both forums. I am happy with these updates, but note that I am also the editor of this document. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 May 2005 20:51:03 +0000 Date: Tue, 24 May 2005 13:49:27 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt (fwd) Message-ID: <20050524134652.P88814@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20050524134652.N88814@kummer.juniper.net> Hi All, This starts a two week CCAMP WG Last call on: draft-ietf-ccamp-inter-domain-framework-02.txt Please send your comments to the list (preferably) or to the authors latest by June 7, 23:59 GMT. Thanks, Kireeti. ------- ---------- Forwarded message ---------- Date: Mon, 23 May 2005 15:39:15 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Framework for Inter-Domain MPLS Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-inter-domain-framework-02.txt Pages : 19 Date : 2005-5-23 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 May 2005 19:44:11 +0000 Message-Id: <200505241940.PAA05820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-crankback-05.txt Date: Tue, 24 May 2005 15:40:41 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-crankback-05.txt Pages : 33 Date : 2005-5-24 In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-crankback-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-crankback-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-24154849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-crankback-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-crankback-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-24154849.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 23 May 2005 19:41:29 +0000 Message-Id: <200505231939.PAA02520@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-02.txt Date: Mon, 23 May 2005 15:39:15 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Framework for Inter-Domain MPLS Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-inter-domain-framework-02.txt Pages : 19 Date : 2005-5-23 This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-23144815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-23144815.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 19 May 2005 09:34:44 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Incoming communication from OIF Date: Thu, 19 May 2005 10:32:39 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Hi, We have received a communication from the OIF. You can see it at http://www.olddog.co.uk/incoming.htm The text can be seen below. Note that there is no action required from us at this time, but if anyone believes there is any information we should send them. Adrian ========== To: Mr. Adrian Farrel, WG Co-Chair for IETF CCAMP Mr. Kireeti Kompella, WG Co-Chair for IETF CCAMP Dear Sirs, The OIF would like to inform you that at the 1Q2005 OIF Meeting, a new project was initiated to document the OIF requirements for Neighbor Discovery. The scope of this project is as follows: This project is targeted to identify the attribute information that must be exchanged in order to support the automatic initialization of the control plane when new links are discovered. Identifying the requirements will require: 1. Understanding Operational Scenarios where discovery will be used. While automatic initialization will reduce the operations intervention required to initialize new links, there may be cases where operators will not want discovery to automatically place links under the control of the Control Plane. Understanding the operational scenarios will allow for development of appropriate requirements. 2. Identify the attributes required by the Control Plane for initializing links. When discovery is allowed to place links into the Control Plane, the attribute information required by the Control Plane functions for the link must be identified. Further, since the attributes of a link may change over time, it is necessary to identify what sort of change in attributes must be possible without requiring the link to be re-initialized. 3. Identify and recommend solutions to the security issues that come from the discovery process exchanging Control Plane attributes. We intend to keep the ITU and IETF informed about this project and welcome your future cooperation. Thank you, Jim Jones, OIF Technical Committee Chair cc: Trey Malpass, Jonathan Sadler Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 18 May 2005 13:24:57 +0000 Message-ID: <000a01c55bac$c462a9b0$1700a8c0@kan> From: "Lei Lei" To: Cc: , "Leilei" Subject: Re:questions on draft-ietf-ccamp-gmpls-recovery-analysis-05 Date: Wed, 18 May 2005 21:23:23 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C55BEF.D26A7270" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C55BEF.D26A7270 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQogICAgRmlyc3Qgb2YgYWxsLCBJIHdvdWxkIGxpa2UgdG8gdGhhbmsgTXIgRmFycmVsIGZvciBr aW5kbHkgb2ZmZXJpbmcgbWUgc3VjaCBhIGdyZWF0IGhlbHAgYW5kIE1yICBQYXBhZGltaXRyaW91 IGZvciB0YWtpbmcgdGhlIHRpbWUgYW5kIHRyb3VibGUgdG8gYW5zd2VyIG15IHF1ZXN0aW9ucy4g SG93ZXZlciwgSSBzdGlsbCBoYXZlIHNvbWUgZGlmZmljdWx0eSBpbiB1bmRlcnN0YW5kaW5nIHRo ZSBpZGVhIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDguNC4xIG9mIGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtcmVjb3ZlcnktYW5hbHlzaXMtMDUuIEknbSBzb3JyeSBmb3IgYm90aGVyaW5nIHlvdSB3aXRo IG15IHF1ZXN0aW9ucyxidXQgbmVpdGhlciBtZSBub3IgbXkgY29sbGVhZ3VlcyBjYW4gY2xlYXIg dGhpcyBjb25mdXNpb24uICAgIA0KDQogICBGcm9tIHRoZSBsYXN0IGVtYWlsLCBJIHVuZGVyc3Rh bmQgdGhhdCB0aGUgZXNzZW5jZSBvZiB0aGUgaWRlYSBpcyB0byBtYXhpbWl6ZSB0aGUgcmF0aW8g YmV0d2VlbiBvdmVyLXByb3Zpc2lvbmVkIGJhbmR3aWR0aCBhbmQgYWN0dWFsIGJhbmR3aWR0aCB0 aGF0IGNhbiBiZSBjb21taXR0ZWQgYnkgYXNzdW1pbmcgb3Zlci1wcm92aXNpb25pbmcgaXMgdXNl ZCBmb3Igc2hhcmVkIHJlY292ZXJ5IHB1cnBvc2VzLiBNeSBxdWVzdGlvbnMgYXJlIGFzIGZvbGxv d3M6DQoNCjEuIFRoZSBjb25jZXB0IG9mIG92ZXItc3Vic2NyaXB0aW9uIGluIHJlY292ZXJ5IHJl c291cmNlIHNoYXJpbmcuIENhbiBJIGRlc2NyaWJlIHRoZSBvdmVyLXByb3Zpc2lvbmVkIGJhbmR3 aWR0aCBhcyB0aGUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgcmVjb3ZlcnkgYmFuZHdpZHRo IHRoYXQgc2hvdWxkIGJlIGFsbG9jYXRlZCBpZiBhIGRlZGljYXRlZCBwcm90ZWN0aW9uIHNjaGVt ZSBpcyBhc3N1bWVkIGFuZCB0aGUgcmVjb3ZlcnkgYmFuZHdpZHRoIHRoYXQgaXMgYWN0dWFsbHkg IHJlc2VydmVkIGNvbnNpZGVyaW5nIHJlY292ZXJ5IHJlc291cmNlIHNoYXJpbmc/IFRoYXQgaXMs IHRoZSBhbW91dCBvZiBiYW5kd2lkdGggIHRoYXQgaXMgc2F2ZWQgYnkgcmVjb3ZlcnkgcmVzb3Vy Y2Ugc2hhcmluZz8NCg0KMi4gVGhlIG1lYW5pbmcgb2YgUltpXS4gSW4gdGhlIGRyYWZ0LCBpdCBp cyBzYWlkIHRoYXQgUltpXSBpcyB0aGUgYW1vdW50IG9mIGJhbmR3aWR0aCBjdXJyZW50bHkgYWxs b2NhdGVkIGZvciBzaGFyZWQgcmVjb3ZlcnkgIGFuZCByW2ldIGlzIHRoZSBhY3R1YWwgYmFuZHdp ZHRoIGNvbW1pdHRlZCBmb3Igc2hhcmVkIHJlY292ZXJ5LiBIb3dldmVyLCB0aGlzIGRlZmluaXRp b24gb2YgUltpXSBpcyBub3QgY2xlYXIgZW5vdWdoIGZvciBtZS4gQ2FuIEkgdW5kZXJzdGFuZCBy W2ldIGFzIHRoZSByZWNvdmVyeSBiYW5kd2lkdGggYWN0dWFsbHkgcmVzZXJ2ZWQgb24gdGhlIGxp bmssIGFuZCBSW2ldIGFzIHRoZSBiYW5kd2lkdGggdGhhdCBzaG91bGQgYmUgYWxsb2NhdGVkIGlm IGEgZGVkaWNhdGVkIHByb3RlY3Rpb24gc2NoZW1lIGlzIGFzc3VtZWQ/IFNvIFJbaV0gLSByW2ld IGlzIHRoZSBhbW91bnQgb2YgYmFuZHdpZHRoIGN1cnJlbnRseSBzYXZlZCBieSByZWNvdmVyeSBy ZXNvdXJjZSBzaGFyaW5nPyBBbHNvLGluIHRoZSBmaWd1cmUgYmVsb3csIGRvZXMgcltpXSBtZWFu IHRoZSBiYW5kd2lkdGggZnJvbSBwb2ludCAxIHRvIHBvaW50IDMgb3IgZnJvbSBwb2ludCAyIHRv IHBvaW50IDQ/IERvZXMgUltpXSBtZWFucyB0aGUgYmFuZHdpZHRoIGZyb20gcG9pbnQgMSB0byBw b2ludCA2IG9yIGZyb20gcG9pbnQgNSB0byBwb2ludCA3Pw0KDQozLiBGcm9tIHRoZSBmaWd1cmUg YmVsb3cgaXQgc2VlbXMgdGhhdCBiW2ldIGVxdWFscyB0byBNYXhpbXVtIExTUCBCYW5kd2lkdGgs IGlzIGl0IHRydWU/IGJbaV0gaXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQgYXMgdGhlIHN1bSBwZXIg VEUgbGluayBpIG9mIHRoZSBiYW5kd2lkdGggY29tbWl0dGVkIGZvciB3b3JraW5nIExTUHMgYW5k IG90aGVyIHJlY292ZXJ5IExTUHMgKHRodXMgZXhjZXB0ICJzaGFyZWQgYmFuZHdpZHRoIiBMU1Bz KS4gSXQgc2VlbXMgdGhhdCBiW2ldIGlzIHRoZSBhbW91bnQgb2YgYWxsb2NhdGVkIGJhbmR3aWR0 aCB0aGF0IGNhbm5vdCBiZSBzaGFyZWQgd2l0aCBjdXJyZW50IExTUC4gVGh1cywgaXQgaXMgc3Ry YW5nZSB0aGF0IGJbaV0gc2hvdWxkIGJlIGVxdWFscyB0byBNYXhpbXVtIExTUCBCYW5kd2lkdGgs IHdoaWNoIGVxdWFscyB0byB0aGUgVW5yZXNlcnZlZCBCYW5kd2lkdGguIEJ1dCBvdGhlcndpc2Us IHdoYXQgZG9lcyB0aGUgPC0tLS0tLSBiIC0tLS0tLT4gaW4gdGhlIGZpZ3VyZSBiZWxvdyBtZWFu Pw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3IC0g LS0tLS0tLS0tLSBNYXggUmVzZXJ2YWJsZSBCYW5kd2lkdGggDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIC0tLS0tICBeICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYgIHxSIC0tLS0tfCAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNSAgfCAgLS0tLS0gIHwg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSAtLS0t LSAgICB8bWF4X1IgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLS0tLSAgICB8IA0KICAgLS0tLS0tLS0gIFRFIGxpbmsgQ2FwYWNpdHkgICAgICAg ICAgICAgICA0IC0gLS0tLS0tIHwgLSBNYXhpbXVtIFRFIExpbmsgQmFuZHdpZHRoIA0KICAgLS0t LS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzIHxyIC0tLS0tICB2IA0KICAg LS0tLS0gICAgIDwtLS0tLS0gYiAtLS0tLS0+ICAgICAgICAgICAgICAyIC0gLS0tLS0tLS0tLSBN YXhpbXVtIExTUCBCYW5kd2lkdGggDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0tLS0gDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0tLS0gDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLS0tLSANCiAgIC0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLS0tLSAgDQogICAtLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0tLS0gPC0tLSBNaW5pbXVtIExTUCBCYW5kd2lkdGggDQogICAtLS0t LS0tLSAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIC0tLS0tLS0tLS0gMCAN Cg0KICBJIHN0aWxsIGhhdmUgc29tZSBvdGhlciBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoaXMgc2Vj dGlvbiwgYnV0IEkgdGhpbmsgdGhhdCBpZiBJIGNhbiBnZXQgdGhlIGFib3ZlIHR3byBxdWVzdGlv bnMgY2xlYXIsIHBlcmhhcHMgSSBjYW4gZmlndXJlIG91dCB0aGUgb3RoZXJzIGJ5IG15c2VsZi4g SSdsbCBiZSB3YXJtbHkgbG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcmVwbHlzLg0KDQpCZXN0IHJl Z2FyZHMNCg0KTGVpIExlaQ== ------=_NextPart_000_0007_01C55BEF.D26A7270 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjIxODAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmYgYmFja2dyb3VuZD0iIj48Rk9OVCBzaXplPTI+PC9GT05UPjxC Uj48Rk9OVCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgRmlyc3Qgb2YgYWxsLCBJIHdvdWxk IGxpa2UgdG8gdGhhbmsgTXIgRmFycmVsIGZvciANCmtpbmRseSBvZmZlcmluZyBtZSBzdWNoIGEg Z3JlYXQgaGVscCBhbmQgTXImbmJzcDsgUGFwYWRpbWl0cmlvdSBmb3IgdGFraW5nIHRoZSANCnRp bWUgYW5kIHRyb3VibGUgdG8gYW5zd2VyIG15IHF1ZXN0aW9ucy4gSG93ZXZlciwgSSBzdGlsbCBo YXZlIHNvbWUgZGlmZmljdWx0eSANCmluIHVuZGVyc3RhbmRpbmcgdGhlIGlkZWEgZGVzY3JpYmVk IGluIHNlY3Rpb24gOC40LjEgb2YgDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXJlY292ZXJ5LWFu YWx5c2lzLTA1LiBJJ20gc29ycnkgZm9yIGJvdGhlcmluZyB5b3Ugd2l0aCBteSANCnF1ZXN0aW9u cyxidXQgbmVpdGhlciBtZSBub3IgbXkgY29sbGVhZ3VlcyBjYW4gY2xlYXIgdGhpcyANCmNvbmZ1 c2lvbi4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPjxCUj4mbmJzcDsmbmJzcDsgRnJvbSB0aGUgbGFz dCBlbWFpbCwgSSANCnVuZGVyc3RhbmQgdGhhdCB0aGUgZXNzZW5jZSBvZiB0aGUgaWRlYSBpcyB0 byBtYXhpbWl6ZSB0aGUgcmF0aW8gYmV0d2VlbiANCm92ZXItcHJvdmlzaW9uZWQgYmFuZHdpZHRo IGFuZCBhY3R1YWwgYmFuZHdpZHRoIHRoYXQgY2FuIGJlIGNvbW1pdHRlZCBieSANCmFzc3VtaW5n IG92ZXItcHJvdmlzaW9uaW5nIGlzIHVzZWQgZm9yIHNoYXJlZCByZWNvdmVyeSBwdXJwb3Nlcy4g TXkgcXVlc3Rpb25zIA0KYXJlIGFzIGZvbGxvd3M6PEJSPjxCUj4xLiBUaGUgY29uY2VwdCBvZiBv dmVyLXN1YnNjcmlwdGlvbiBpbiByZWNvdmVyeSByZXNvdXJjZSANCnNoYXJpbmcuIENhbiBJIGRl c2NyaWJlIHRoZSBvdmVyLXByb3Zpc2lvbmVkIGJhbmR3aWR0aCBhcyB0aGUgdGhlIGRpZmZlcmVu Y2UgDQpiZXR3ZWVuIHRoZSByZWNvdmVyeSBiYW5kd2lkdGggdGhhdCBzaG91bGQgYmUgYWxsb2Nh dGVkIGlmIGEgZGVkaWNhdGVkIA0KcHJvdGVjdGlvbiBzY2hlbWUgaXMgYXNzdW1lZCBhbmQgdGhl IHJlY292ZXJ5IGJhbmR3aWR0aCB0aGF0IGlzIGFjdHVhbGx5Jm5ic3A7IA0KcmVzZXJ2ZWQgY29u c2lkZXJpbmcgcmVjb3ZlcnkgcmVzb3VyY2Ugc2hhcmluZz8gVGhhdCBpcywgdGhlIGFtb3V0IG9m IA0KYmFuZHdpZHRoJm5ic3A7IHRoYXQgaXMgc2F2ZWQgYnkgcmVjb3ZlcnkgcmVzb3VyY2Ugc2hh cmluZz88QlI+PEJSPjIuIFRoZSANCm1lYW5pbmcgb2YgUltpXS4gSW4gdGhlIGRyYWZ0LCBpdCBp cyBzYWlkIHRoYXQgUltpXSBpcyB0aGUgYW1vdW50IG9mIGJhbmR3aWR0aCANCmN1cnJlbnRseSBh bGxvY2F0ZWQgZm9yIHNoYXJlZCByZWNvdmVyeSZuYnNwOyBhbmQgcltpXSBpcyB0aGUgYWN0dWFs IGJhbmR3aWR0aCANCmNvbW1pdHRlZCBmb3Igc2hhcmVkIHJlY292ZXJ5LiBIb3dldmVyLCB0aGlz IGRlZmluaXRpb24gb2YgUltpXSBpcyBub3QgY2xlYXIgDQplbm91Z2ggZm9yIG1lLiBDYW4gSSB1 bmRlcnN0YW5kIHJbaV0gYXMgdGhlIHJlY292ZXJ5IGJhbmR3aWR0aCBhY3R1YWxseSByZXNlcnZl ZCANCm9uIHRoZSBsaW5rLCBhbmQgUltpXSBhcyB0aGUgYmFuZHdpZHRoIHRoYXQgc2hvdWxkIGJl IGFsbG9jYXRlZCBpZiBhIGRlZGljYXRlZCANCnByb3RlY3Rpb24gc2NoZW1lIGlzIGFzc3VtZWQ/ IFNvIFJbaV0gLSByW2ldIGlzIHRoZSBhbW91bnQgb2YgYmFuZHdpZHRoIA0KY3VycmVudGx5IHNh dmVkIGJ5IHJlY292ZXJ5IHJlc291cmNlIHNoYXJpbmc/IEFsc28saW4gdGhlIGZpZ3VyZSBiZWxv dywgZG9lcyANCnJbaV0gbWVhbiB0aGUgYmFuZHdpZHRoIGZyb20gcG9pbnQgMSB0byBwb2ludCAz IG9yIGZyb20gcG9pbnQgMiB0byBwb2ludCA0PyBEb2VzIA0KUltpXSBtZWFucyB0aGUgYmFuZHdp ZHRoIGZyb20gcG9pbnQgMSB0byBwb2ludCA2IG9yIGZyb20gcG9pbnQgNSB0byBwb2ludCANCjc/ PEJSPjxCUj4zLiBGcm9tIHRoZSBmaWd1cmUgYmVsb3cgaXQgc2VlbXMgdGhhdCBiW2ldIGVxdWFs cyB0byBNYXhpbXVtIExTUCANCkJhbmR3aWR0aCwgaXMgaXQgdHJ1ZT8gYltpXSBpcyBkZWZpbmVk IGluIHRoZSBkcmFmdCBhcyB0aGUgc3VtIHBlciBURSBsaW5rIGkgb2YgDQp0aGUgYmFuZHdpZHRo IGNvbW1pdHRlZCBmb3Igd29ya2luZyBMU1BzIGFuZCBvdGhlciByZWNvdmVyeSBMU1BzICh0aHVz IGV4Y2VwdCANCiJzaGFyZWQgYmFuZHdpZHRoIiBMU1BzKS4gSXQgc2VlbXMgdGhhdCBiW2ldIGlz IHRoZSBhbW91bnQgb2YgYWxsb2NhdGVkIA0KYmFuZHdpZHRoIHRoYXQgY2Fubm90IGJlIHNoYXJl ZCB3aXRoIGN1cnJlbnQgTFNQLiBUaHVzLCBpdCBpcyBzdHJhbmdlIHRoYXQgYltpXSANCnNob3Vs ZCBiZSBlcXVhbHMgdG8gTWF4aW11bSBMU1AgQmFuZHdpZHRoLCB3aGljaCBlcXVhbHMgdG8gdGhl IFVucmVzZXJ2ZWQgDQpCYW5kd2lkdGguIEJ1dCBvdGhlcndpc2UsIHdoYXQgZG9lcyB0aGUgJmx0 Oy0tLS0tLSBiIC0tLS0tLSZndDsgaW4gdGhlIGZpZ3VyZSANCmJlbG93IA0KbWVhbj88QlI+PEJS PjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo3IC0gLS0t LS0tLS0tLSBNYXggUmVzZXJ2YWJsZSBCYW5kd2lkdGggDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNw OyAtLS0tLSZuYnNwOyBeJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjYmbmJzcDsgfFIgLS0tLS18Jm5ic3A7IA0KPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjUmbmJzcDsgfCZu YnNwOyAtLS0tLSZuYnNwOyB8IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0gLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsg fG1heF9SIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7IHwg PEJSPiZuYnNwOyZuYnNwOyAtLS0tLS0tLSZuYnNwOyBURSBsaW5rIA0KQ2FwYWNpdHkmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQombmJzcDs0IC0gLS0tLS0tIHwgLSBNYXhpbXVtIFRFIExpbmsgQmFu ZHdpZHRoIDxCUj4mbmJzcDsmbmJzcDsgDQotLS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCjMgfHIgLS0tLS0mbmJzcDsgdiA8QlI+Jm5ic3A7Jm5ic3A7IC0tLS0t Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0tLS0gYiANCi0tLS0tLSZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQoyIC0gLS0tLS0tLS0tLSBNYXhpbXVtIExTUCBCYW5kd2lkdGggPEJS PiZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0gPEJSPiZuYnNwOyZuYnNw OyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0gPEJSPiZuYnNwOyZuYnNwOyANCi0tLS0tJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KLS0tLS0gPEJSPiZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0m bmJzcDsgPEJSPiZuYnNwOyZuYnNwOyANCi0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLS0tLS0gJmx0Oy0t LSBNaW5pbXVtIExTUCBCYW5kd2lkdGggPEJSPiZuYnNwOyZuYnNwOyAtLS0tLS0tLSANCjAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQombmJzcDsxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0gMCA8QlI+PEJSPiZu YnNwOyBJIHN0aWxsIGhhdmUgc29tZSANCm90aGVyIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhpcyBz ZWN0aW9uLCBidXQgSSB0aGluayB0aGF0IGlmIEkgY2FuIGdldCB0aGUgYWJvdmUgDQp0d28gcXVl c3Rpb25zIGNsZWFyLCBwZXJoYXBzIEkgY2FuIGZpZ3VyZSBvdXQgdGhlIG90aGVycyBieSBteXNl bGYuIEknbGwgYmUgDQp3YXJtbHkgbG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcmVwbHlzLjxCUj48 QlI+QmVzdCByZWdhcmRzPEJSPjxCUj5MZWkgDQpMZWk8L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0007_01C55BEF.D26A7270-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 May 2005 19:29:42 +0000 Message-ID: <428A454F.7030705@psg.com> Date: Tue, 17 May 2005 21:26:07 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, leil@buptnet.edu.cn, adrian@olddog.co.uk Subject: Re: Questions on draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit adrian, see below Adrian Farrel wrote: > Hi, > Posting this question on behalf of Lei Lei who has had some difficulty > subscribing to the list. > Thanks, > Adrian > === > The section 8.4.1 of draft-ietf-ccamp-gmpls-recovery-analysis-05.txt > discusses how to realize recovery resource sharing using GMPLS protocols. > It draws the conclusion that no further extensions of GMPLS routing > protocols are needed to perform this task, since the use of Maximum > Reservable Bandiwidth, the Unreserved Bandwidth and the Maximum LSP > Bandwidth is sufficient for the purpose. However, I do not quite follow > this idea. > I've read the [KODIALAM1], [KODIALAM2] and [GLI] papers, which is > referred to in the draft, even before I read this draft. I have no > problem in understanding the ideas described in those papers, In those > papers, the Maximum TE Link Bandwidth is divided into three parts: the > capacity committed for working LSPs, and capacity reserved for backup > LSPs, and the unallocated capacity. The Partial Information routing > algorithm needs to know the above three values in order to compute the > optimal path. The Full Information routing algorithm in [GLI] needs > still more information. However, section 8.4.1 of > draft-ietf-ccamp-gmpls-recovery-analysis-05.txt > claims that only the value of Maximum Reservable Bandiwidth, the > Unreserved Bandwidth and the Maximum LSP Bandwidth need to be avaiable > for recovery resource sharing, as shown in the figure below. But I do > not understand how. > 1. I do not understand the relationships between the Max Reservable > Bandwidth, Maximum LSP Bandwidth and the Unreserved Bandwidth. the relationships have been defined in various GMPLS routing documents, the profile proposed is by definition informational and shows a way to use these parameters such as to obtain the stated objective all the below questions are specific to local policy rules and subject to initial configuration (except the nominal link capacity which is determined by the interface capability) > 1.a Why should the difference between Max Reservable Bandwidth and the > Maximum LSP Bandwidth be the Maximum Shareable Bandwidth? > 1.b Why should the difference between the Max Reservable Bandwidth and > the Maximum TE Link Bandwidth be the amount of bandwidth currently > allocated for shared recovery? > The Max Reservable Bandwidth should be larger than the Maximum TE > Link Bandwidth, then how to set the exact value of Max Reservable > Bandwidth? > Is it decided by policy or can be calculated by some equations? > Is it a constant value during network operation or change over time? > 1.c Why should the difference between the Maximum TE Link Bandwidth and > the Maximum LSP Bandwidth be the actual bandwidth committed for > shared recovery instead of the sum of the bandwidth committed for > working LSPs and the actual bandwidth committed for shared recovery? > 2. What is the routing algorithm supposed to be used in this method? > I suppose the working LSP can be calculated with SPF algorithm on the > network topology where the links whose Maximum LSP Bandwidth smaller > than the request bandwidth are pruned? But how to calculate the optimum > backup path? Is it similar with the Partial Information approach? If it > is, I fail to see how this could be done. additional information needed for the partial information model is to find a way to determine the (shared) bandwidth reserved on each link by protecting LSPs that have already been set up (soft-provisioning) - so instead here of requiring such additional information, the setup discussed in this section is proposing to maximize the ratio between over-provisioned bandwidth and actual bandwidth that can be committed by assuming over-provisioning is used for shared recovery purposes; the considerations do not detail the exact algorithm but assess that the available information is enough achieve this computation > - ---------- Max Reservable Bandwidth > | ----- ^ > |R ----- | > | ----- | > - ----- |max_R > ----- | > -------- TE link Capacity - ------ | - Maximum TE Link Bandwidth > ----- |r ----- v > ----- <------ b ------> - ---------- Maximum LSP Bandwidth > ----- ----- > ----- ----- > ----- ----- > ----- ----- > ----- ----- <--- Minimum LSP Bandwidth > -------- 0 ---------- 0 > > Best regards > Lei Lei > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 May 2005 10:18:22 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: leil@buptnet.edu.cn, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Questions on draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Date: Tue, 17 May 2005 11:16:43 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Hi, Posting this question on behalf of Lei Lei who has had some difficulty subscribing to the list. Thanks, Adrian === The section 8.4.1 of draft-ietf-ccamp-gmpls-recovery-analysis-05.txt discusses how to realize recovery resource sharing using GMPLS protocols. It draws the conclusion that no further extensions of GMPLS routing protocols are needed to perform this task, since the use of Maximum Reservable Bandiwidth, the Unreserved Bandwidth and the Maximum LSP Bandwidth is sufficient for the purpose. However, I do not quite follow this idea. I've read the [KODIALAM1], [KODIALAM2] and [GLI] papers, which is referred to in the draft, even before I read this draft. I have no problem in understanding the ideas described in those papers, In those papers, the Maximum TE Link Bandwidth is divided into three parts: the capacity committed for working LSPs, and capacity reserved for backup LSPs, and the unallocated capacity. The Partial Information routing algorithm needs to know the above three values in order to compute the optimal path. The Full Information routing algorithm in [GLI] needs still more information. However, section 8.4.1 of draft-ietf-ccamp-gmpls-recovery-analysis-05.txt claims that only the value of Maximum Reservable Bandiwidth, the Unreserved Bandwidth and the Maximum LSP Bandwidth need to be avaiable for recovery resource sharing, as shown in the figure below. But I do not understand how. 1. I do not understand the relationships between the Max Reservable Bandwidth, Maximum LSP Bandwidth and the Unreserved Bandwidth. 1.a Why should the difference between Max Reservable Bandwidth and the Maximum LSP Bandwidth be the Maximum Shareable Bandwidth? 1.b Why should the difference between the Max Reservable Bandwidth and the Maximum TE Link Bandwidth be the amount of bandwidth currently allocated for shared recovery? The Max Reservable Bandwidth should be larger than the Maximum TE Link Bandwidth, then how to set the exact value of Max Reservable Bandwidth? Is it decided by policy or can be calculated by some equations? Is it a constant value during network operation or change over time? 1.c Why should the difference between the Maximum TE Link Bandwidth and the Maximum LSP Bandwidth be the actual bandwidth committed for shared recovery instead of the sum of the bandwidth committed for working LSPs and the actual bandwidth committed for shared recovery? 2. What is the routing algorithm supposed to be used in this method? I suppose the working LSP can be calculated with SPF algorithm on the network topology where the links whose Maximum LSP Bandwidth smaller than the request bandwidth are pruned? But how to calculate the optimum backup path? Is it similar with the Partial Information approach? If it is, I fail to see how this could be done. - ---------- Max Reservable Bandwidth | ----- ^ |R ----- | | ----- | - ----- |max_R ----- | -------- TE link Capacity - ------ | - Maximum TE Link Bandwidth ----- |r ----- v ----- <------ b ------> - ---------- Maximum LSP Bandwidth ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- <--- Minimum LSP Bandwidth -------- 0 ---------- 0 Best regards Lei Lei Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 16 May 2005 12:36:14 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk, zinin@psg.com, kireeti@juniper.net Reply-To: adrian@olddog.co.uk Subject: Proposal to kill Tunnel Trace Date: Mon, 16 May 2005 13:33:08 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Hi, Notwithstanding the reasonably mature state of draft-ietf-ccamp-tunproto-01 there appears to be zero support in the community to complete the work, and more importantly to implement it. So, although we have a requirements RFC and a charter action for this work, I am proposing that we kill this I-D (or at least let it expire peacefully). We have discussed this amongst the authors and ADs and have agreement, but I need to offer you the opportunity to comment against (or for) this proposal. Be aware that if you are in favor of keeping this work alive, you will need to commit to work on the draft, and also to implement it. We can assume that if/when people start to implement and deploy hierarchical LSPs in earnest they may come back and resurrect the I-D. If any of you objects to this (for example, you know of imminent plans to implement, or deployments that will really need this work), then please speak up now. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 14 May 2005 21:31:20 +0000 Message-ID: <01c101c558cc$5b0034c0$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Bill Fenner" , "WG Milestone Tracker" Subject: draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt ready for AD review Date: Sat, 14 May 2005 20:06:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt is ready for AD review with a view to moving it along to IETF last call and IESG review. The draft has: - been reviewed by me as CCAMP chair - been through CCAMP WG last call - been updated from these steps to my satisfaction. The I-D is targeted at the Standards Track. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 14 May 2005 18:46:07 +0000 Message-ID: <01a101c558b5$4e61e310$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" Cc: Subject: Re: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Sat, 14 May 2005 17:26:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, This is a very good point. We have been struggling with this for a while (I believe that Bert gave me a pointer, but I don't think I understood the issue properly before). Thanks to your explanation and the new text in the MIB guideline, we have taken care of the issue. Cheers, Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Friday, March 18, 2005 9:29 AM Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt > This MIB contains several 'enumerations' except they are not enumerations but > text in > DESCRIPTION clauses - gmplsTunnelGPid gmplsTunnelSwitchingType > gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference. So these are > not defined anywhere in SMI; and as this points out, these values will be added > to in future RFC. > > I think these should be in a MIB under IANA control and there is already a way > to do just that, namely to put them in an IANA MIB (as opposed to a standards > track MIB) with the RFC specifying under what conditions the IANA MIB can be > updated (standards track, IESG, expert etc). > > This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which > also points to previous examples of this. And this issue has already surfaced, > albeit obliquely, on this list once before in the context of > IANAItuProbableCause which uses this procedure and is now published as part of > the Alarm MIB (RFC 3877). > > Not to do this now creates extra work in the future; when an implementor has to > create their own SMI and whenever these values need to be updated. > > Tom Petch > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 14 May 2005 15:10:01 +0000 Message-ID: <019401c55897$0cb52030$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Sat, 14 May 2005 15:57:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, Next in the series of your comments on the GMPLS MIBs. > A minor comment; this document has > false (0), > in several places; following RFC 2579, I think this should be > false (2) OK > A larger question,; this mib augments tables in the mpls mib (RFC3812); is there > a reason why the AUGMENTS construct was not used? You and I discussed this on the list a bit. I think we came to the conclusion that: - Augments is what we intended - it fits the usage - the indexing is needed because the new table is a separate table. So, no action, but I expect the MIB Doctors (TM) will pick up on it if there are any issues. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 14 May 2005 15:09:54 +0000 Message-ID: <019301c55897$051d7610$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Subject: Re: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt Date: Sat, 14 May 2005 15:50:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, Thanks for your comments which we are (finally) addressing. > I find the IANA Considerations section less than clear. I suggest that you > differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB OK. > I would also reword it slightly as follows. > > ** MPLS and GMPLS related standards track MIB modules are rooted under the > mplsStdMIB subtree. > > One of the MIB modules contained in this document extends tables > contained in MPLS MIB modules. OK > ** The two MIB modules contained in this document, like that in > GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree. OK > ** New assignments in the mplsStdMIB subtree can only be made via a Standards > Action as specified in [RFC2434]. OK > 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB > > ** The IANA is requested to assign { mplsStdMIB yy } to the > GMPLS-LABEL-STD-MIB module specified in this document. Yes, as above. Thanks, Adrian and Tom (Your other emails on these MIBs will be responded to separately.) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 13 May 2005 17:17:51 +0000 Message-ID: <013601c557df$c3042740$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "JP Vasseur" Cc: , "Scott Bradner" , , "Bill Fenner" Subject: Re: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Fri, 13 May 2005 18:18:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit JP, Thanks for your proposals. After consultation, I find that under the new IPR rules we do not make specific reference to IPR disclosures in I-Ds or RFCs. Instead, the boilerplate says that there "may be" IPR claims, and refers the reader to the Web pages. This is a future-proof technique. Therefore, I have tweaked your suggestions below. > 1. Text is added to the I-D as follows. > > The procedures described in this document are the subject of an > Intellectual Property Rights claim. For this reason, the procedures are > entirely optional within an MPLS or GMPLS network. Implementations that > do not support the procedures described in this document will > interoperate seamlessly with those that do. > Further, an implementation that does not support the procedures > described in this document will not be impacted or implicated by a > neighboring implementation that does implement the procedures. Replace this paragraph with... The procedures described in this document are entirely optional within an MPLS or GMPLS network. Implementations that do not support the procedures described in this document will interoperate seamlessly with those that do. Further, an implementation that does not support the procedures described in this document will not be impacted or implicated by a neighboring implementation that does implement the procedures. > An ingress implementation that chooses not to support the procedures > described in this document may still achieve re-optimization by > periodically issuing a speculative make-before-break replacement of an > LSP without trying to discovery whether a more optimal path is > available in a downstream domain. Such a procedure would not be in > conflict with any mechanisms not already documented in [RFC3209] and > [RFC3473]. Second paragraph is fine. > 2. The I-D should be updated with comments arising from the WG last > call. Yes please. > 3. The I-D should be progressed as an informational RFC Yes. This is advisable. Please update the I-D and submit it. I will then forward it to Alex for AD review. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 13 May 2005 11:50:11 +0000 Message-ID: <003f01c557b2$25417850$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Incoming liaison from ITU-T SG13 on L1VPNs Date: Fri, 13 May 2005 12:51:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have just received the following liaison from ITU-T Study Group 13. The pdf version of the liaison can be found at incoming liaisons page of the alternate CCAMP web site. http://www.olddog.co.uk/ccamp.htm The liaison will find its way onto the IETF's liaison pages when the Secretariat have processed it. Since the liaison is for action, we can expect to respond with a statement of our progress on L1VPNs. Cheers, Adrian ======= From: Marco Carugi, Rapporteur of ITU-T SG13 Question 2 To: IETF Routing Area CCAMP Working Group Subject: L1VPN related work collaboration For: Action Deadline: 29th August 2005 SG 13 would like to thank the IETF CCAMP WG for your liaison replies in the area of L1VPNs, informing us about your recent progress on this subject, as well as the new mailing list creation. Thank you for your review of the ITU-T documents on service level requirements and framework for L1VPNs, now published as Y.1312 (Layer 1 Virtual Private Network Generic Requirements and Architecture Elements) and Y.1313 (Layer 1 Virtual Private Network service and network architectures). We are aware that these service level requirements and framework have been summarized in the Internet-Draft draft-takeda-l1vpn-framework, and that work is ongoing in the IETF community to assess the suitability of existing IETF protocols to meet the requirements within the context of the framework. We appreciate and would definitely like to continue our collaboration with the IETF on this subject so that, following the analysis of the suitability of the existing IETF protocols for L1VPN service delivery, any necessary protocol extensions are appropriately accomplished within the IETF. Please continue to keep us informed about your progress in the area of L1VPNs. Our next meeting is planned for August 25 - September 9 2005 in Geneva. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 13 May 2005 11:30:22 +0000 Message-ID: <002001c557af$276d3950$04919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last call complete on draft-ietf-ccamp-rsvp-restart-ext-02.txt Date: Fri, 13 May 2005 12:26:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Editors, Please update the draft with the last call comments and resubmit it. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 13 May 2005 04:35:10 +0000 Message-ID: <004b01c556ef$1b2be080$c1849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Arun Satyanarayana" , "Reshad Rahman" Subject: Re: Working group last call on draft-ietf-ccamp-rsvp-restart-ext-02.txt Date: Thu, 12 May 2005 13:29:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have some comments on this draft Please fix the boilerplate. The Secretariat are now policing this tightly and will fail any future submissions. You would do well to run idnits over any future version before submitting it. Please indicate at the head of the I-D what the intended category of the draft is. Presumably Standards Track. Do you believe that this I-D updates RFC3473? If so, please put this in the header of the draft. Ditto RFC2961. There are some instances of "should" / "should not" / "must" / 'recommended" in lower case. Please be careful that you mean this. Abstract uses two acronyms (ERO and LSP) without expanding them. Introduction I fell that it would be helpful to state why we are working on graceful restart. Probably by expaning the first sentence to say very briefly what graceful restart actually is. Something like "to synchronize the control plane state of a restarting control plane component with the data plane state that has been preserved, carrying user traffic during the control plan component downtime." Introduction (and throughout) You talk about a restarting "node", but I think you really mean a restarting control plane signaling component (often called a signaling controller). It is helpful to distinguish the control plane from the data plane for graceful restart, and I think that the term "node" does not help. I appreciate that RFC3473 uses the term "nodal fault". Maybe you can make a terminology statement at the top of the I-D to the effect that where you say "node" you are generally refering to the signaling controller for the data plane switch. Section 2.3 Transmission of RecoveryPath messages There is a slight contradiction or confusion here. First, the text says that the downstream neighbor "should spread the messages across 1/2 the Recovery Time interval." But then it points out that retransmission may be required with up to three retransmissions, and says... "the period between re-send attempts SHOULD be such that at least 3 attempts are completed before the expiry of 1/2 the Recovery Time interval." This implies that (if the Message ID mechanim is not in use) the downstream neighbor SHOULD spread the messages across 1/6 the Recovery Time interval. But see also section 3.3.1 where the Srefreshes are sent for the first time over 1/4 of the interval and may also be retransmitted (presumably up to 3 times). Sections 2.4.1, 2.4.2, 3.3.2 (twice) s/triggered Path/trigger Path/ Section 2.4.3 Twice in this section you give "SHOULD" actions regarding the discard of partial state. What are the implications of not following this advice? Why is it not "MUST"? Section 3.2.2 "There are no compatibility issues introduced in this section." You probably mean "in the procedures defined in section 3.2.1." Section 3.3, 3.3.1 (including title), and 3.3.2 (including title) Several instances of "RecoveryPath-related Srefresh message" can be reduced to ""RecoveryPath Srefresh message" Section 3.3.1 "A neighbor of a restarting node generates one or more" Is this "MAY", "SHOULD" or "MUST"? Section 3.3.1 Please be very careful to say "RecoveryPath Srefresh" every time you mean it, because normal Srefresh processing may continue in parallel. Otherwise your text will be interpretted to mean that normal Srefresh is broken. In fact, you should make clear that these procedures do no impact normal Srefresh processing. Section 3.3.2 See the timing comments for section 2.3. Here you say... The restarted node MAY spread the transmission of such triggered Path messages across 1/2 of the remaining Recovery Period to allow the downstream RSVP neighbor sufficient processing time. Do you mean, up until the end of the 3rd quarter, or do you mean for each Path message, spread over half of the remaining time to the end of the whole interval? Section 5 If an outside influence is able to cause the control plane of a node to go down and come up again, this will obviously impact the controllability of the LSPs that transit that node. Your procedures restore the ability to control those LSPs and so they have a positive influence on security, and you should say so. On the other hand, your procedures impact the neighboring upstream nodes and cause them to perform increased processing possibly to the detrement of their handling of other control plane messages. Thus, by toggling one node I can impact LSPs that do not transit that node. You need to flag this and point out that it is handled by setting the Recovery Time sufficiently large. Section 6 This section is very weak! Could you please name the objects/messages and point to the sections where they are defined. The object is not "of form 10bbbbbb". That is the form of the C-Num. Section 6 So you think there is a need for IANA to track the bit allocations in the Flags field of the Message_ID List object? Section 7.2 You might want to consider removing this reference since the I-D is, I think, expired without any intention of being regenerated. Section 11 The year is now 2005 :-) Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 12 May 2005 21:41:01 +0000 Message-ID: <4283CCF2.3030306@cisco.com> Date: Thu, 12 May 2005 14:38:58 -0700 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, Reshad Rahman , "Arun Satyanarayana (asatyana)" Subject: Re: Working group last call on draft-ietf-ccamp-rsvp-restart-ext-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adrian, Thanks for the comments. Will update the I-D and respin. Thanks, Arun =============================================================== Adrian Farrel wrote: > Hi, > > I have some comments on this draft > > Please fix the boilerplate. The Secretariat are now policing this tightly > and will fail any future submissions. You would do well to run idnits over > any future version before submitting it. > > Please indicate at the head of the I-D what the intended category of the > draft is. Presumably Standards Track. > > Do you believe that this I-D updates RFC3473? If so, please put this in > the header of the draft. > Ditto RFC2961. > > There are some instances of "should" / "should not" / "must" / > 'recommended" in lower case. Please be careful that you mean this. > > Abstract uses two acronyms (ERO and LSP) without expanding them. > > Introduction > I fell that it would be helpful to state why we are working on graceful > restart. Probably by expaning the first sentence to say very briefly what > graceful restart actually is. Something like "to synchronize the control > plane state of a restarting control plane component with the data plane > state that has been preserved, carrying user traffic during the control > plan component downtime." > > Introduction (and throughout) > You talk about a restarting "node", but I think you really mean a > restarting control plane signaling component (often called a signaling > controller). It is helpful to distinguish the control plane from the data > plane for graceful restart, and I think that the term "node" does not > help. > I appreciate that RFC3473 uses the term "nodal fault". > Maybe you can make a terminology statement at the top of the I-D to the > effect that where you say "node" you are generally refering to the > signaling controller for the data plane switch. > > Section 2.3 Transmission of RecoveryPath messages > There is a slight contradiction or confusion here. > First, the text says that the downstream neighbor "should spread the > messages across 1/2 the Recovery Time interval." But then it points out > that retransmission may be required with up to three retransmissions, and > says... "the period between re-send attempts SHOULD be such that at least > 3 attempts are completed before the expiry of 1/2 the Recovery Time > interval." > This implies that (if the Message ID mechanim is not in use) the > downstream neighbor SHOULD spread the messages across 1/6 the Recovery > Time interval. > But see also section 3.3.1 where the Srefreshes are sent for the first > time over 1/4 of the interval and may also be retransmitted (presumably up > to 3 times). > > Sections 2.4.1, 2.4.2, 3.3.2 (twice) > s/triggered Path/trigger Path/ > > Section 2.4.3 > Twice in this section you give "SHOULD" actions regarding the discard of > partial state. What are the implications of not following this advice? Why > is it not "MUST"? > > Section 3.2.2 > "There are no compatibility issues introduced in this section." > You probably mean "in the procedures defined in section 3.2.1." > > Section 3.3, 3.3.1 (including title), and 3.3.2 (including title) > Several instances of "RecoveryPath-related Srefresh message" can be > reduced to ""RecoveryPath Srefresh message" > > Section 3.3.1 > "A neighbor of a restarting node generates one or more" > Is this "MAY", "SHOULD" or "MUST"? > > Section 3.3.1 > Please be very careful to say "RecoveryPath Srefresh" every time you mean > it, because normal Srefresh processing may continue in parallel. Otherwise > your text will be interpretted to mean that normal Srefresh is broken. In > fact, you should make clear that these procedures do no impact normal > Srefresh processing. > > Section 3.3.2 > See the timing comments for section 2.3. > Here you say... > The restarted node MAY spread the transmission of > such triggered Path messages across 1/2 of the remaining Recovery > Period to allow the downstream RSVP neighbor sufficient processing > time. > Do you mean, up until the end of the 3rd quarter, or do you mean for each > Path message, spread over half of the remaining time to the end of the > whole interval? > > Section 5 > If an outside influence is able to cause the control plane of a node to go > down and come up again, this will obviously impact the controllability of > the LSPs that transit that node. Your procedures restore the ability to > control those LSPs and so they have a positive influence on security, and > you should say so. > On the other hand, your procedures impact the neighboring upstream nodes > and cause them to perform increased processing possibly to the detrement > of their handling of other control plane messages. Thus, by toggling one > node I can impact LSPs that do not transit that node. You need to flag > this and point out that it is handled by setting the Recovery Time > sufficiently large. > > Section 6 > This section is very weak! > Could you please name the objects/messages and point to the sections where > they are defined. > The object is not "of form 10bbbbbb". That is the form of the C-Num. > > Section 6 > So you think there is a need for IANA to track the bit allocations in the > Flags field of the Message_ID List object? > > Section 7.2 > You might want to consider removing this reference since the I-D is, I > think, expired without any intention of being regenerated. > > Section 11 > The year is now 2005 :-) > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 May 2005 19:46:05 +0000 Message-Id: <200505061943.PAA28973@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-02.txt Date: Fri, 06 May 2005 15:43:47 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Transport Network View of the Link Management Protocol Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-transport-lmp-02.txt Pages : 17 Date : 2005-5-6 The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-transport-lmp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-6153147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-transport-lmp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-6153147.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 05 May 2005 20:26:09 +0000 Message-Id: <200505052023.QAA08958@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-00.txt Date: Thu, 05 May 2005 16:23:56 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Addressing and Messaging in Generalized Multi-Protocol Label Switching (GMPLS) Networks Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-gmpls-addressing-00.txt Pages : 17 Date : 2005-5-5 This document explains and clarifies addressing and messaging in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSR) based on experience gained in deployments and interoperability testing and proper interpretation of published RFCs. The document recommends a proper approach for the interpretation and choice of address and identifier fields within GMPLS protocols and references specific control plane usage models. It also examines some common GMPLS Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling message processing issues and recommends solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-addressing-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-addressing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-5160822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-addressing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-5160822.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 May 2005 18:33:11 +0000 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , "Scott Bradner" , , "Bill Fenner" From: JP Vasseur Subject: Re: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Tue, 3 May 2005 14:31:04 -0400 To: "Adrian Farrel" Hi, First of all, thanks to the CCAMP WG chair for helping out in the resolution of this issue. The draft represents an important technique which, in our opinion, is a valuable addition to the management and operation of LSPs in MPLS and GMPLS networks especially where those LSPs traverse multiple domains. We have looked at this function carefully, but do not believe that it can be achieved by any other technique that would not also be potentially covered by this IPR disclosure. Therefore we propose the following steps: 1. Text is added to the I-D as follows. The procedures described in this document are the subject of an Intellectual Property Rights claim. For this reason, the procedures are entirely optional within an MPLS or GMPLS network. Implementations that do not support the procedures described in this document will interoperate seamlessly with those that do. Further, an implementation that does not support the procedures described in this document will not be impacted or implicated by a neighboring implementation that does implement the procedures. An ingress implementation that chooses not to support the procedures described in this document may still achieve re-optimization by periodically issuing a speculative make-before-break replacement of an LSP without trying to discovery whether a more optimal path is available in a downstream domain. Such a procedure would not be in conflict with any mechanisms not already documented in [RFC3209] and [RFC3473]. 2. The I-D should be updated with comments arising from the WG last call. 3. The I-D should be progressed as an informational RFC Thanks. JP. On Apr 7, 2005, at 8:52 AM, Adrian Farrel wrote: > Please see below a response from the Counsel for Nortel Networks with > regard to my enquiry about their IPR disclosure for > draft-ietf-ccamp-loose-path-reopt-00.txt. > > The working group must now decide whether it wishes to pursue the > techniques described in the I-D notwithstanding the IPR claim, or > whether > it should seek out an alternative technology. > > Discussion please. > > Thanks, > Adrian > ----- Original Message ----- > From: "Michelle Lee" > To: "Adrian Farrel" > Cc: "'Kireeti Kompella'" ; "Richard Weiss" > > Sent: Wednesday, April 06, 2005 5:54 PM > Subject: RE: Nortel Networks Statement on IPR claimed in > draft-ietf-ccamp-loose-path-reopt-00.txt > > >> Dear Mr. Farrel, >> >> Thank you for your email. >> >> Unfortunately, I am not in a position to answer these questions >> specifically, especially since they would require my providing > privileged >> and/or confidential information. We believe, however, our intentions >> are >> clearly set forth in and by our conforming disclosure and declaration >> statement to IETF with respect to IETF Internet Draft >> draft-ietf-ccamp-loose-path-reopt-00.txt, and that experts in the area > can >> probably better determine relevance of the identified patent therein. >> >> Kind Regards, >> Michelle Lee >> Counsel, IP Law >> Nortel Networks >> >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Monday, March 21, 2005 4:32 PM >> To: weissr@nortelnetworks.com; mleelaw@nortelnetworks.com >> Cc: 'Kireeti Kompella'; ccamp@ops.ietf.org >> Subject: Nortel Networks Statement on IPR claimed in >> draft-ietf-ccamp-loose-path-reopt-00.txt >> >> >> >> Dear Richard and Michelle, >> >> Thank you for submitting your Patent Disclosure >> ( >> > reopt > -0 >> 0.txt> >> > http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path- > reopt-00 >> .txt) >> with respect to IETF Internet Draft >> draft-ietf-ccamp-loose-path-reopt-00.txt. >> >> I would be grateful if you could clarify two points to help me > understand >> this discolsure further. >> >> 1. The disclosure states that: >> Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus and >> method of maintaining timely topology data within a link state > routing >> network" may contain claims that may be necessary for practicing >> a >> resulting IETF Standard based on this Internet Draft. >> Could you provide more detail about what aspects of >> draft-ietf-ccamp-loose-path-reopt-00.txt you believe may be impacted > by >> this disclosure? >> >> 2. Can you clarify whether the "fair, reasonable, reciprocal, and >> non-discriminatory terms" referenced in the disclosure include the >> intention, in the event that the referenced draft becomes an >> Internet >> Standard, not to assert the patent except that some party asserts a >> patent >> patent it owns or controls against Nortel? >> By way of an example of wording that covers this intention, can I > draw >> your attention to a completely unrelated IPR disclosure at >> > >> http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt >> >> Thank you for any clarification you are able to offer. >> >> Please note that I am copying this email to Kireeti Kompella who > co-chairs >> the IETF's CCAMP working group with me. The CCAMP working group > developed >> the Internet-Draft in question > (draft-ietf-ccamp-loose-path-reopt-00.txt) >> and so I am also copying this email to the CCAMP mailing list. >> >> Best regards, >> Adrian Farrel >> -- >> Adrian Farrel >> Old Dog Consulting >> Phone: +44 (0) 1978-860944 >> Fax: +44 (0) 870-130-5411 >> adrian@olddog.co.uk >> >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 May 2005 23:18:57 +0000 Message-ID: <08d701c54f6d$40b2dae0$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder: Enforcement of Updated IPR Boilerplate Date: Mon, 2 May 2005 22:49:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI ----- Original Message ----- From: "IETF Secretariat" Sent: Monday, May 02, 2005 8:42 PM Subject: Reminder: Enforcement of Updated IPR Boilerplate > This message is to remind you that as of Friday, May 6, 2005, > all Internet-Drafts that are submitted to the IETF Secretariat > for posting must include the IPR-related notices and disclaimers > specified in RFC 3978 (BCP 78), "IETF Rights in Contributions." > The required notices and disclaimers can be found in Section 5, > "Notices Required in IETF Documents," of RFC 3978, and in > Section 3, "IPR-Related Notices Required in Internet-Drafts," > of the recently revised "Guidelines to Authors of Internet-Drafts" > (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" > document also provides additional guidance regarding the > placement of these notices. > > Please note that the required notices and disclaimers must > be reproduced verbatim since they have been legally reviewed > and formally adopted as part of the IETF process. The > Secretariat will not accept deviations from the specified > text, nor will it correct the text. Any documents that do > not comply with the requirements of RFC 3978, and with > the most recent version of the "Guidelines" document, will > be returned to the submitter. > > The IETF Secretariat Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 May 2005 03:54:51 +0000 Reply-To: From: "Vishal Sharma" To: "ccamp mailing list" , "ccamp chair" , "ccamp chair" Cc: "Alex Zinin" , "Greg Bernstein" , "Eric Mannie" , "Eric W. Gray" Subject: RE: Document Action: 'Framework for GMPLS-based Control of SDH/SONET Networks' to Informational RFC Date: Sun, 1 May 2005 20:52:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Adrian, Just wanted to be sure what the next step is on this? Are the author's required to make the changes suggested by the RFC Editor and submit another version? If so, to whom and by when? Thanks, -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of The IESG > Sent: Friday, April 29, 2005 8:23 AM > To: IETF-Announce > Cc: Internet Architecture Board; RFC Editor; ccamp mailing list; ccamp > chair; ccamp chair > Subject: Document Action: 'Framework for GMPLS-based Control of > SDH/SONET Networks' to Informational RFC > > > The IESG has approved the following document: > > - 'Framework for GMPLS-based Control of SDH/SONET Networks ' > as an Informational RFC > > This document is the product of the Common Control and Measurement Plane > Working Group. > > The IESG contact persons are Alex Zinin and Bill Fenner. > > Technical Summary > > GMPLS consists of a suite of protocol extensions to MPLS to make > these protocols more generally applicable, to include - for example > - control of non-packet based switching, and particularly, optical > switching. One area of prime consideration is to use Generalized > MPLS (GMPLS) protocols in upgrading the control plane of optical > transport networks. This document illustrates this process by > describing those extensions to GMPLS protocols that are directed > towards controlling SDH/SONET networks. SDH/SONET networks make > very good examples of this process since they possess a rich > multiplex structure, a variety of protection/restoration options, > are well defined, and are widely deployed. The document discusses > extensions to GMPLS routing protocols to disseminate information > needed in transport path computation and network operations, > together with the extensions to GMPLS label distribution protocols > needed for the provisioning of transport circuits. New capabilities > that an GMPLS control plane would bring to SDH/SONET networks, such > as new restoration methods and multi-layer circuit establishment, > are also discussed. > > Working Group Summary > > The CCAMP WG had a consensus on advancing this document. > > Protocol Quality > > The document has been reviewed by the RTG area directorate and > Alex Zinin. > > RFC Editor Note > > Section 1.1 para 2 > > OLD > An MPLS network consists of MPLS nodes called Label Switch Routers > (LSRs) connected via circuits called Label Switched Paths (LSPs). An > LSP is unidirectional and could be of several different types such > as point-to-point, point-to-multipoint, and multipoint-to-point. > NEW > An MPLS network consists of MPLS nodes called Label Switch Routers > (LSRs) connected via Label Switched Paths (LSPs). An > LSP is unidirectional and could be of several different types such > as point-to-point, point-to-multipoint, and multipoint-to-point. > > Replace text in section 7 (Security Considerations) with the following. > > NEW: > > The use of a control plane to provision connectivity through a SONET/SDH > network shifts the security burden significantly from the > management plane > to the control plane. Before the introduction of a control plane, the > communications that had to be secured were between the > management stations > (Element Management Systems or Network Management Systems) and each > network element that participated in the network connection. After the > introduction of the control plane, the only management plane > communication > that needs to be secured is that to the head-end (ingress) > network node as > the end-to-end service is requested. On the other hand, the > control plane > introduces a new requirement to secure signaling and routing > communications between adjacent nodes in the network plane. > > The security risk from impersonated management stations is significantly > reduced by the use of a control plane. In particular, where unsecure > versions of network management protocols such as SNMP versions 1 and 2 > were popular configuration tools in transport networks, the use of a > control plane may significantly reduce the security risk of > malicious and > false assignment of network resources that could cause the > interception or > disruption of data traffic. > > On the other hand, the control plane may increase the number of security > relationships that each network node must maintain. Instead of a single > security relationship with its management element, each network > node must > now maintain a security relationship with each of its signaling and > routing neighbors in the control plane. > > There is a strong requirement for singaling and control plane > exchanges to > be secured, and any protocols proposed for this purpose must be > capable of > secure message exchanges. This is already the case for the > existing GMPLS > routing and signaling protocols. > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 01 May 2005 22:08:59 +0000 Message-ID: <080101c54e9a$8d51b700$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Hiroshi Ohta" Cc: "'Kireeti Kompella'" , , "Bill Fenner" , "Scott Bradner" , , Subject: Response Liaison to Q3/15 on the GMPLS/ASON Lexicography Date: Sun, 1 May 2005 23:10:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: Hiroshi Ohta, Rapporteur of ITU-T Question 3/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: GMPLS / ASON Lexicography For: Information Dear Ohta_san, Thank you for liaising a copy of G.8081 to the IETF CCAMP working group. This has been most useful in the preparation of the latest version of our Internet-Draft that provides a mapping from common GMPLS terms to ASON terminology. The most recent version of this draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt. I must apologise that the current version does not include a reference to G.8081 - this will be remedied in the next revision. We are assuming that most input from SG15 for this draft will come from Q14/15 and have liaised the draft to them for their review. However, if participants in Q3/15 have any comments on the draft we would be very pleased to receive them either in a response liaison or as individual emails on the CCAMP mailing list (see http://www.ietf.org/html.charters/ccamp-charter.html). Best regards, Adrian Farrel and Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 01 May 2005 22:02:39 +0000 Message-ID: <07f401c54e99$a53369a0$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: , "'Kireeti Kompella'" , , "Bill Fenner" , "Scott Bradner" , Subject: Liaison to Q14/15 on the GMPLS / ASON Lexicography Date: Sun, 1 May 2005 23:01:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: Kam Lam, Rapporteur of ITU-T Question 14/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: GMPLS / ASON Lexicography For: Action Deadline: 30th May 2005 Dear Kam, As you will be aware, the CCAMP working group took the output of the very useful terminology discussions held under your auspices in Holmdel earlier this year and created an Internet-Draft to capture and progress the information. The most up-to-date version of this draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt Since this work is heavily dependent on the definition of terms within the ASON architecture, and since much of the text was taken directly from material dictated by Q14/15 participants in Holmdel, we would greatly appreciate it if Q14/15 was able to provide further review input at this stage. As usual, review input in the return of a response liaison is very acceptable, but individuals who wish to contribute to this work further may discuss the draft on the CCAMP mailing list (see http://www.ietf.org/html.charters/ccamp-charter.html) Best regards, Adrian Farrel and Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 01 May 2005 21:54:07 +0000 Message-ID: <07ef01c54e98$7b755610$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: , "'Kireeti Kompella'" , , "Bill Fenner" , "Scott Bradner" , Subject: Response Liaison to Q14/15 on Transport use of LMP Date: Sun, 1 May 2005 22:53:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: Kam Lam, Rapporteur of ITU-T Question 14/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: Response to your Liaison on the Transport Use of LMP For: Information Dear Kam, Thank you for your liaison from Q14/15 dated 9th March 2005 including several observations on the SNPP link construct and the way in which adaptation/termination properties are defined and used in the ASON architecture. This is useful and timely information since it fits with work being done by several members of CCAMP to evaluate and resolve issues associated with multi-region and multi-layer networks. We will make sure that the information is passed along to them. Best regards, Adrian Farrel and Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 01 May 2005 21:48:40 +0000 Message-ID: <07e301c54e97$561f3080$1c849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: , , "Scott Bradner" , "'Kireeti Kompella'" , , "Bill Fenner" Subject: Liaison to ITU-T Q14/15 on The Evaluation of IETF Routing Protocols in the Context of ASON Date: Sun, 1 May 2005 22:46:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: Kam Lam, Rapporteur of ITU-T Question 14/15 From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs Subject: The Evaluation of IETF Routing Protocols in the Context of ASON Routing Requirements For: Action Deadline: 30th May 2005 Dear Kam, As you will be aware a Design Team has been working to evaluate the existing IP-based routing protocols with a view to discovering their applicability to the requirements of the ASON architecture and establishing what, if any, protocol extensions are required. This design team operates under the umbrella of the CCAMP working group within the IETF and is made up of people drawn equally from the IETF and ITU-T communities. The purpose of this liaison is to make you aware of the progress of the Design Team, and to solicit input from Q14/15 in the form of review feedback on the latest output of the Design Team which can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt. The CCAMP working group will soon consider collaborating with other IETF working groups within the Routing Area to provide adequate solutions for the identified ASON routing capabilities. Best regards, Adrian Farrel and Kireeti Kompella