IETF Logo Mail Archive

Re: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments

"Richard Rabbat" <rabbat@alum.mit.edu> Sat, 12 July 2008 04:23 UTC

Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DDB3A6B31 for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 11 Jul 2008 21:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.128
X-Spam-Level:
X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMT8CGn7Z8GQ for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 11 Jul 2008 21:23:30 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB1D23A67D6 for <ccamp-archive@ietf.org>; Fri, 11 Jul 2008 21:23:29 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KHWYP-0008fH-VB for ccamp-data@psg.com; Sat, 12 Jul 2008 04:17:49 +0000
Received: from [209.85.134.187] (helo=mu-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <richard.rabbat@gmail.com>) id 1KHWYL-0008ew-Vl for ccamp@ops.ietf.org; Sat, 12 Jul 2008 04:17:48 +0000
Received: by mu-out-0910.google.com with SMTP id w8so1330946mue.1 for <ccamp@ops.ietf.org>; Fri, 11 Jul 2008 21:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=r2mEvhkg5H0VxeXEWkvRdkIP5TVi+l7KPCtu8Kf96kM=; b=eyfiYGBk2xw3KnzAvEyd5B5YCsSe39rqCAn0CJevqy+lFGKv5R2BVbd6o0bQ816jOw XkrKToK90jcgAJRW4Rh2NaB6j7qDYkmp+ROAFEprCHOLeFYgAsXPUl/H0rJ2kraZD4XJ SpLOnK7lzGKvXOxhr4O8SBeY6L/o+he5z1X/o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=QysKgbOLY0HXZM02gnoUQO4l7V5Y0dV7gYiUfwzKzHJ7zuanRuZ+gCKOle/SHpJdP4 3ZPKnrsRL3NQGHlyeYQXSNCeWazY+nhIEDmyqePYTxPiicK2//2zMLsOtHtMaPi0hy5O w5MXE9aVYhXVgdXIFOl1jc54TtloyzJ5JC28k=
Received: by 10.103.242.14 with SMTP id u14mr5938535mur.65.1215836260366; Fri, 11 Jul 2008 21:17:40 -0700 (PDT)
Received: by 10.103.52.18 with HTTP; Fri, 11 Jul 2008 21:17:40 -0700 (PDT)
Message-ID: <cbe76faa0807112117n23ef5798l9b69ee0c517d552e@mail.gmail.com>
Date: Fri, 11 Jul 2008 21:17:40 -0700
From: Richard Rabbat <rabbat@alum.mit.edu>
To: Jishnu A <jishnu@india.tejasnetworks.com>
Subject: Re: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
Cc: imajuku.wataru@lab.ntt.co.jp, julien.meuric@orange-ft.com, lyong@ciena.com, ccamp <ccamp@ops.ietf.org>
In-Reply-To: <20080711040335.9F629261A03@webmail.india.tejasnetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_15373_5259735.1215836260353"
References: <20080711040335.9F629261A03@webmail.india.tejasnetworks.com>
X-Google-Sender-Auth: 958c702b412b4e24
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

Jishnu,
shouldn't we rather use use a procedure similar to the bandwidth increase
procedure of rfc 3209 (see 4.6.4)?
Richard.

On Thu, Jul 10, 2008 at 9:13 PM, Jishnu A <jishnu@india.tejasnetworks.com>
wrote:

>  Adding ccamp
>
>
>
> Regards,
>
> Jishnu A
>   ------------------------------
>
> *From:* Jishnu A [mailto:jishnu@india.tejasnetworks.com]
> *Sent:* Wednesday, July 09, 2008 11:15 AM
> *To:* 'imajuku.wataru@lab.ntt.co.jp'
> *Cc:* 'julien.meuric@orange-ft.com'; 'lyong@ciena.com'
> *Subject:* draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
>
>
>
> Dear Imajuku,
>
> One aspect presently not covered in the draft is modification of the VCG ID
> keeping the bandwidth same. This would be required in the case where some
> VCG member has to be relinquished for the purpose of reassigning it to some
> other purpose. This with the present architecture would require two calls:
> one for removing a VCG and second one for adding the new VCG ID. I am not
> sure if this is within the scope of this draft.
>
>
>
> If this is within the scope of the draft, my suggestion for it would be to
> have a Action value =4 in which case there are two VCG IDs, the first to be
> removed and the second to be added.
>
>
>
> Regards,
>
> Jishnu A
>
> Lead Engineer
>
> Standards & Technology Group
>
> CTO's Office
>
> Tejas Networks India Ltd
>
> No 58, 1st Main Road,
>
> J.P. Nagar 3rd Phase
>
> Bangalore - 78
>
>
>
> Phone: +91 80 4179 4635
>
> Mail:jishnu@india.tejasnetworks.com<Mail%3Ajishnu@india.tejasnetworks.com>
>
>
>

v2.23.0 | Report a Bug | By Email