Re: AD comments on draft-ietf-nsis-qspec-21

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 <[email protected]> wrote:


From: Georgios Karagiannis <[email protected]>
Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21
To: "Magnus Westerlund" <[email protected]>, "Gerald Ash" <[email protected]>
Cc: "David Black" <[email protected]>, "[email protected]" <[email protected]>, "NSIS" <[email protected]>
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

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis