Subject: AW: [NSIS] QSPEC Comments

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 22 May 2006 16:08:27 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 22 May 2006 09:21:06 -0500

Hi Hannes,

Further comments.

> provide information about the allocation strategy but you do 
> not request IANA to allocate even a single value. 

OK.

> > > > > the QSPEC template (e.g., sender-initiated, receiver-oriented
> > > > > QoS signaling)?

> > > > 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. 

> > 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 of QoS-NSLP doesn't contain the same info as in Section 6 in
the QSPEC.  The latter is oriented toward RMF procedures, which properly
belongs in the QSPEC.  I don't see much overlap between the two
documents with respect to these procedures.  

> > > The tunneled QSPEC is never interpreted in the way how the QoS
> > > NSLP works and hence interior QoS nodes will never see the flag.

> Who is going to interpret it? 

As stated in the QSPEC, the flag is interpreted by the QNI, ingress QNE
(start of tunnel in a domain), egress QNE (end of tunnel in a domain),
or QNR.

Thanks,
Jerry

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 May 2006 17:11:35 +0200

Hi Jerry,

I guess that these two issues are largely a matter of the worksplit 
between the QoS NSLP and the QSPEC template draft. I thought that the 
QoS NSLP deals with signaling aspects but I seem to be wrong.

Ciao
Hannes