AW: [NSIS] QSPEC Comments

"Tschofenig, Hannes" <hannes.tschofenig@siemens.com> Mon, 22 May 2006 14:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB5C-0008HR-Lz; Mon, 22 May 2006 10:08:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB5A-0008HD-Vt for nsis@ietf.org; Mon, 22 May 2006 10:08:28 -0400
Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiB59-00025q-G4 for nsis@ietf.org; Mon, 22 May 2006 10:08:28 -0400
Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k4ME8Nng014552; Mon, 22 May 2006 16:08:23 +0200
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k4ME8No9030441; Mon, 22 May 2006 16:08:23 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 16:08:22 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [NSIS] QSPEC Comments
Date: Mon, 22 May 2006 16:08:27 +0200
Message-ID: <A5D2BD54850CCA4AA3B93227205D8A30696A43@MCHP7IEA.ww002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [NSIS] QSPEC Comments
Thread-Index: AcZ1odRCtn6HIQz5SteZEa5CaDorswH9wAAQAAMJbcAAAEPqIAAAhfyQ
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, nsis <nsis@ietf.org>
X-OriginalArrivalTime: 22 May 2006 14:08:22.0966 (UTC) FILETIME=[2FB03560:01C67DA9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc:
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org

Hi Jerry, 

thanks for your quick response. 

> Hi Hannes,
> 
> > > > - You shouldn't request IANA to allocate value for QOSMs in the
> > > > QSPEC template document.
> 
> > > Then where should that be done, in the QoS-NSLP document perhaps?
> > >  IMO it needs to be done either in the QSPEC document or QoS-NSLP
> > > document.
> 
> > I think that this should be done in QOSMs. 
> > That's the right place.
> 
> That makes no sense to me.  A registry must be established to 
> be *used*
> by new QOSMs, as they are developed.  We don't want each QOSM I-D to
> establish a new registry.  I think the registry as specified in the
> QSPEC is OK.  It's also OK with me to put it in the QoS-NSLP document.

I see where we have a disagreement. 

You can create a registry in the QSPEC template for later usage by the
QOSMs but you cannot request IANA to already allocate values for QOSMs
that are described in separate specifications. 

Hence, you create a registry at the QSPEC template document and you
provide information about the allocation strategy but you do not request
IANA to allocate even a single value. 

> 
> > > > - Why do you need information of the type of QoS signaling in 
> > > > the QSPEC template (e.g., sender-initiated, 
> receiver-oriented QoS
> > > > signaling)?
> 
> > > Section 6 specifies procedures for using QSPEC in the RMF, for
> > > various scenarios.  For example, the "RSVP-style" scenario
> > > specified in Section 6.2 was specifically requested at one of the
> > > Interim NSIS meetings.  It ensures backward compatibility with
> > > RSVP.
> 
> > But you have this information already in the QoS NSLP and 
> it would be
> > trivial to indicate this info when the QoS NSLP interacts with the
> > RMF.  I think it is duplicate info. 
> 
> I don't see any such info in the QoS-NSLP document.  Where are you
> looking?  In any case, since these procedures relate to the RMF, they
> belong in the QSPEC rather than QoS-NSLP.

When the QoS NSLP starts an interaction then it needs to know whether it
is doing a sender-initiated or a receiver-initiated QoS signaling
exchange.

Section 4, for example, shows the different message exchanges. 

> 
> > > > - Is the idea of the tunneled parameter flag inline with the QoS
> > > > NSLP understanding of tunneling?
> 
> > > AFAIK it is consistent.  The flag is set as specified in Section
> > > 4.5.2:
> > > 
> > > "  Each QSPEC parameter has an associated 
> 'tunneled-parameter flag'.
> > >    When a RESERVE message is tunneled through a domain, 
> QNEs inside
> > >    the domain cannot update read-write parameters.  The egress QNE
> > >    in a domain has two choices: either it is configured to have 
> > >    the knowledge to update the parameters correctly.  Or it cannot
> > >    update the parameters.  In this case it MUST set the 
> > >    tunneled-parameter flag to tell the QNI (or QNR) that the
> > >    information contained in the read-write parameter is 
> most likely
> > >    incorrect (or a lower bound)."
> > > 
> > > The egress QNE (end of tunnel) sets the flag accordingly.  Do you
> > > think this is inconsistent?
> 
> > The tunneled QSPEC is never interpreted in the way how the QoS NSLP
> > works and hence interior QoS nodes will never see the flag.
> 
> What you say is correct.  Interior QNEs will not see the flag, and
> nothing is stated in the QSPEC that contradicts that.
Who is going to interpret it? 


Ciao
Hannes

> 
> Thanks,
> Jerry
> 

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis