Re: Moving forward with the CCAMP charter

Tomohiro Otani <otani@kddilabs.jp> Wed, 17 August 2005 01:09 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5CQJ-00072X-Ri for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 21:09:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28152 for <ccamp-archive@ietf.org>; Tue, 16 Aug 2005 21:08:53 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Czd-0004uf-Lm for ccamp-archive@ietf.org; Tue, 16 Aug 2005 21:45:33 -0400
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5CKX-000Mso-Cx for ccamp-data@psg.com; Wed, 17 Aug 2005 01:02:57 +0000
Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5CKW-000MsZ-Nc for ccamp@ops.ietf.org; Wed, 17 Aug 2005 01:02:56 +0000
Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id A6691EC8D7; Wed, 17 Aug 2005 10:02:52 +0900 (JST)
Received: from platinum.onw.kddilabs.jp (platinum.onw.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 46211EC8D4; Wed, 17 Aug 2005 10:02:52 +0900 (JST)
Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:570e] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:570e]) by platinum.onw.kddilabs.jp (Postfix) with ESMTP id D6300578103; Wed, 17 Aug 2005 09:56:16 +0900 (JST)
Message-ID: <43028CCB.2090607@kddilabs.jp>
Date: Wed, 17 Aug 2005 10:03:07 +0900
From: Tomohiro Otani <otani@kddilabs.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511
X-Accept-Language: ja, en-us, en
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: JP Vasseur <jvasseur@cisco.com>, ccamp@ops.ietf.org, zinin@psg.com, 'Kireeti Kompella' <kireeti@juniper.net>
Subject: Re: Moving forward with the CCAMP charter
References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> <01d401c5a294$477581f0$4f849ed9@Puppy> <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com>
In-Reply-To: <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
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: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit

Hi Adrian,

Being related with your text and JP's messages, I would ask you
to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt.
Is this related with a kind of baseline for (1) Analysis of inter-domain
issues ?

So far, there is a proposed draft of GMPLS inter-domain signaling
as we discussed in Paris, but there is no draft of GMPLS inter-domain
routing definition whether it is with TE extension or not.
(your framework draft covers these points)

Regards,

tomo




JP Vasseur wrote:

>Hi Adrian,
>
>On Aug 16, 2005, at 2:53 PM, Adrian Farrel wrote:
>
>>> (1) Analysis of inter-domain issues for disjoint and protected paths
>>>        - Informational I-D to close off the topic and devolve to PCE
>>>        * first version of WG draft
>>>        * submit for IESG review
>>>
>>> Could you briefly elaborate on this item ?
>>>
>>
>> I think we have the need for an informational I-D that is a bit  
>> like the
>> existing inter-domain framework I-D, but that examines the more  
>> complex
>> question of the provisioning of disjoint and protection paths across
>> domain boundaries. I am aware that there a lot of ideas out there  
>> and that
>> there has been a lot of research. I think we need to capture an  
>> overview.
>>
>
>ok fair enough ... I'll be happy to provide my input on the topic (as  
>you can imagine ;-))
>
>> It is my (personal - not WG chair) opinion that this I-D will point  
>> firmly
>> at the PCE WG. But just as for single paths we discovered that  
>> there are
>> some (limited) scenarios for single paths where signaling is  
>> suitable on
>> its own, we may find some solutions for diverse and protected paths.
>>
>>
>>> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful-
>>> shutdown, you may want to add draft-leroux-ccamp-ctrl-
>>> saturation-01.txt ?
>>>
>>
>> Yes. I am inclined to add a work item for "control plane robustness".
>>
>
>Thanks.
>
>JP.
>
>> Adrian
>>
>
>
>  
>