Subject: AW: [NSIS] QSPEC Comments

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

Hi Jerry, 

thanks for your response. 

> Hi Hannes,
> 
> Thanks for the comments. 
> 
> > -----Original Message-----
> > From: Tschofenig, Hannes [mailto:[email-masked]] 
> > Sent: Friday, May 12, 2006 5:09 AM
> > To: nsis
> > Subject: [NSIS] QSPEC Comments
> > 
> > Hi all
> > 
> > I have a few minor comments for the QSPEC draft:
> > 
> > - Use either 'QoS NSLP' or 'QoS-NSLP' terminology. The QoS 
> NSLP draft
> > uses 'QoS NSLP'
> > - Don't use RFC 2119 language in examples (e.g., Section 
> > 4.3). The same is true for RFC 2119 language in the appendix. 
> > - Review RFC 2119 language in the text. Example: First sentence in
> > Section 4.6: MAY is inappropriate there. 
> > - Ability to define mandatory QoS parameters in QOSMs no clear
> > - Reference to [NSIS-EXTENSIBILITY] in the IANA consideration 
> > section is not a good idea. It also needs to be removed from the
> > normative reference since otherwise this document will be blocked. 
> 
> Agree with all the above comments.
> 
> > - 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. 

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

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

> 
> > - Use capitalized words in captions and headlines. The RFC 
> editor will
> > thank you.  
> > 
> > Other comments have been posted by Andrew already (e.g., 
> definition of
> > mandatory parameters). 
> 
> Haven't heard further from Andrew RE error-codes discussion, 
> so I think
> we're ready now to update the QSPEC I-D.

Ok. 

Ciao
Hannes

> 
> Thanks,
> Jerry
> 
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
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 08:58:08 -0500

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

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

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

> > > - 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:
> > 
> >    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?

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

Thanks,
Jerry