Your Discusses and Comments on draft-ietf-ccamp-mpls-gmpls-interwork-fmwk
"Adrian Farrel" <adrian@olddog.co.uk> Fri, 28 December 2007 19:10 UTC
Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8KbD-00078P-3X for ccamp-archive@ietf.org; Fri, 28 Dec 2007 14:10:27 -0500
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8KbC-0000Xq-I3 for ccamp-archive@ietf.org; Fri, 28 Dec 2007 14:10:27 -0500
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1J8KOr-000F3C-4z for ccamp-data@psg.com; Fri, 28 Dec 2007 18:57:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3
Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1J8KOi-000F1g-2D for ccamp@ops.ietf.org; Fri, 28 Dec 2007 18:57:39 +0000
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id lBSItuHJ006718; Fri, 28 Dec 2007 18:56:00 GMT
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id lBSItqAP006666; Fri, 28 Dec 2007 18:55:54 GMT
Message-ID: <04fe01c84983$45362960$0501a8c0@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: David Ward <dward@cisco.com>, Tim Polk <tim.polk@nist.gov>
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>, Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp>, Ross Callon <rcallon@juniper.net>, ccamp@ops.ietf.org
References: <3525C9833C09ED418C6FD6CD9514668C02F39770@emailwf1.jnpr.net> <476BBD36.8020806@lab.ntt.co.jp>
Subject: Your Discusses and Comments on draft-ietf-ccamp-mpls-gmpls-interwork-fmwk
Date: Fri, 28 Dec 2007 18:55:48 -0000
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Hi, I think we have proposals to resolve your issues with draft-ietf-ccamp-mpls-gmpls-interwork-fmwk. Can you confirm that they would meet your needs? Thanks, Adrian === Tim Polk Discuss "This is a discuss discuss. Personally, I find the phased migration model terrifying. Selective introduction of features seems like a great opportunity to perform a DoS attack on your own network. Are there features of GMPLS that assume the existence of other features for consistent operation? It seems like you are developing your own interim internal "standards" that need to be self-consistent. Is this really a good thing for the IETF to recommend?" Ross is right that the intention of CCAMP in this I-D was to not recommend the phased model (although it should be noted that this is exactly what the vendors are doing)-: So section 4.3 is a fine place to add additional warnings as follows... > Interoperability concerns though are exacerbated by this migration > model, unless all LSRs in the network are updated simultaneously and > there is a clear understanding of which subset of features are to be > included in the hybrid LSRs. Interworking between a hybrid LSR and an > unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS > LSR as described in the previous sections and puts the unchanged LSR > in the role of an MPLS LSR. The potential for different hybrids > within the network will complicate matters considerably. This model is, therefore, only appropriate for use when the set of new features to be deployed is well known and limited, and where there is a clear understanding of and agreement on this set of features by the network operators of the ISP(s) involved as well as all vendors whose equipment will be involved in the migration. === Tim Polk Comment "Section 5, Paragraph 4 first sentence currently reads: The second strategy for PSC and non-PSC networks is to migrate from the PSC network to GMPLS, first, and then enable GMPLS within the non-PSC network. I suggest: The second strategy is to migrate from the PSC network to GMPLS, first, and then enable GMPLS within the non-PSC network." This should actually read... The second strategy is to migrate the PSC network to GMPLS first, and then enable GMPLS within the non-PSC network." === Dave Ward Comment "There is no mention of using PCEs for this functionality." PCE could fit usefully into the Island model and the Integrated model. It would not play any valuable role in the Phased model. I think the best place to add a reference would be in section 5.1 since PCE may provide a component in the migration toolkit. This would not be as strong as a recommendation to use PCE since it is clear that the use of PCE is not a prerequisite for migration. So we could add... 5.1.4. Path Computation Element The Path Computation Element (PCE) [RFC4655] may provide an additional tool to aid MPLS to GMPLS migration. If a layered network approach (Section 5.1.1) is used, PCEs may be used to facilitate the computation of paths for LSPs in the different layers [PCE-INTER-LAYER]. And to section 12.2 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering," draft-ietf-pce-inter-layer-frwk, work in progress.
- Your Discusses and Comments on draft-ietf-ccamp-m… Adrian Farrel