Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

Yes, I was more interested in the answer than necessary addition to the
documents. However, the text proposal is good.

Sorry for not being able to respond before the cut-off.

/Magnus

Gerald Ash skrev:
> Hi Georgios,
>  
> I agree with your suggestion, thank you for that.
>  
> Magnus, does Georgios' suggestion take care of your comment #11?
>  
> Thanks,
> Regards,
> Jerry
> 
> --- On *Sat, 10/24/09, Georgios Karagiannis /<karagian at cs.utwente.nl>/*
> wrote:
> 
> 
>     From: Georgios Karagiannis <karagian at cs.utwente.nl>
>     Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21
>     To: "Magnus Westerlund" <magnus.westerlund at ericsson.com>, "Gerald
>     Ash" <gash5107 at yahoo.com>
>     Cc: "David Black" <black_david at emc.com>,
>     "draft-ietf-nsis-qspec at tools.ietf.org"
>     <draft-ietf-nsis-qspec at tools.ietf.org>, "NSIS" <nsis at ietf.org>
>     Date: Saturday, October 24, 2009, 3:33 AM
> 
>     Hi Magnus
> 
>     Regarding comment 11:
>     >>> 11. This may seem out of context but I do want to know the
>     answer to how
>     >>> the situation is handled when QNI and QNR are neighbors on a non QoS
>     >>> enabled network.
>     >> 
>     >> What "situation" are you referring to here?  IMO you can't have a QNI
>     >> and QNR in a "non QoS enabled network".  By definition, a QNI and QNR
>     >> are only defined in an NSIS enabled network (i.e., a QoS enabled
>     network).
>     >
>     >I am asking what is happening in these cases where a QNI has the QNR as
>     >peer and there are no network support. Clearly you will not get any
>     QoS,
>     >but is it clear to both QNI and QNR that this is the situation?
>     >
> 
>     I think that the solution for this situation is provided by QoS-NSLP. In
>     particular, this situation is detected by uing the generic flag BREAK
>     (B), see Section 5.1.1 Common header, in the QoS-NSLP draft, see below:
> 
>     BREAK (B) - when set, indicates that there are routers along the path
>     where QoS cannot be provided.
> 
>     Maybe it will be good to add a sentence in the QSPEC draft that
>     emphasizes."
> 
>     "As specified in QoS-NSLP, when there are routers along the path between
>     QNI and QNR where QoS cannot be provided then the QoS-NSLP generic flag
>     BREAK (B) is set."
> 
>     Best regards,
>     Georgios
> 
> 


-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------