Re: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.tx t
dimitri papadimitriou <dpapadimitriou@psg.com> Fri, 23 July 2004 16:37 UTC
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 MAA07711 for <ccamp-archive@ietf.org>; Fri, 23 Jul 2004 12:37:13 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo33d-0001n3-UE for ccamp-archive@ietf.org; Fri, 23 Jul 2004 12:38:06 -0400
Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bo2qz-000Joh-LM for ccamp-data@psg.com; Fri, 23 Jul 2004 16:25:01 +0000
Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bo2qy-000Jnr-0h; Fri, 23 Jul 2004 16:25:00 +0000
Message-ID: <41013BD9.6080000@psg.com>
Date: Fri, 23 Jul 2004 18:24:57 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Drake <jdrake@calient.net>
CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org
Subject: Re: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.tx t
References: <9D42C6E086250248810DCADA39CE7EFC017AE4DE@nimbus.chromisys.com>
In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC017AE4DE@nimbus.chromisys.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
john, there is no default or recommended behaviour described in section 4.3 of the bundling i-d, now, if one assumes that, by default, component recording (only) must be provided, there is no possibility to deliver the expected feature as the components selected on a link local basis would be unknown to the ingress, also, there is more complex problem that even if you assume for instance an bundled link and record two subobjects of the form <router_id, interface_id> one for the bundle and one for the component there is an ordering rule that should be define to link the associated label subobject if present; i hope it clarifies that 1) there is something to be addressed, 2) mechanism proposed is one possible way to address it 3) intend was to make the default behaviour of recording at the same level than ERO and trigger additional information using this flag (the equivalent of label recording btw) thanks, - dimitri. John Drake wrote: > Dimitri, > > This flag isn't needed. Once a node selects the component link, it is that > link that is in the RRO. > > Thanks, > > John > > >>-----Original Message----- >>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>Sent: Friday, July 23, 2004 5:47 AM >>To: ccamp@ops.ietf.org >>Subject: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt >> >>All, there is one issue that is flagged in Section 7.1 in this draft >> >><http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te- >>bundled-links-00.txt> >> >>as needing to poll from the working group to see whether to use Session_ >>Attributes or LSP_Attributes to flag component link recording and close >>accordingly >> >>" If a node desires component link recording, the "Component Link >> Recording desired" flag (value TBD) should be set in the >> LSP_ATTRIBUTES object, object that is defined in [RSVP-TE- >> ATTRIBUTE]. Another alternate is to use an available flag in the >> SESSION_ATTRIBUTE object [RFC3209]. The later makes the component >> link recording request similar to the label recording request." >> >>thanks for the feedback, >>- dimitri > > > . >
- RE: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bun… John Drake
- Re: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bun… dimitri papadimitriou