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
|