Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Ken, 

See below. 

>Hannes,
>
>I always appreciate your determination, but I'm just not 
>convinced by your arguments :-)....more below...
>
>> Hi Ken,
>>
>> Don't give up so quickly. I know, you are not the author of the 
>> document but let us look at the text in detail and my proposal for 
>> change:
>>
>>
>> 2.3.  Recommendations on implementation of an Admitted Telephony 
>> Service
>>       Class
>>
>>    It is the belief of the authors that either PHB implementation
>>    described in Section 2.1, if coupled with adequate AAA 
>and capacity
>>    admission procedures as described in Section 2.2, are 
>sufficient to
>>    provide the services required for an Admitted Telephony service
>>    class.
>>
>>
>> CHANGE PROPOSAL:
>> "
>>    It is the belief of the working group that either PHB 
>> implementation
>>    described in Section 2.1, if coupled with adequate AAA 
>and capacity
>>    admission procedures as described in Section 2.2, are 
>sufficient to
>>    provide the services required for an Admitted Telephony service
>>    class.
>> "
>>
>> REASON: I hope the working group believes it as well and not 
>only the 
>> authors.
>
>fine and reasonable change from my perspective.
>
>>    If preemption is required, as described in section 2.3.5.2 of
>>    [RFC4542], this provides the tools for carrying out the 
>preemption.
>>    If preemption is not in view, or if used in addition to preemptive
>>    services, the application of different thresholds 
>depending on call
>>    precedence has the effect of improving the probability of call
>>    completion by admitting preferred calls at a time that other calls
>>    are being refused.  Routine and priority traffic can be admitted
>>    using the same DSCP value, as the choice of which calls are 
>> admitted
>>    is handled in the admission procedure executed in the control 
>> plane,
>>    not the policing of the data plane.
>>
>>    On the point of what protocols and procedures are required for
>>    authentication, authorization, and capacity admission, we 
>note that
>>    clear standards do not at this time exist for bandwidth brokers, 
>> NSIS
>>    has not at this time been finalized and in any event is limited to
>>    unicast sessions, and that RSVP has been standardized and has the
>>    relevant services.  We therefore recommend the use of RSVP at the
>>    UNI.  Procedures at the NNI are business matters to be discussed
>>    between the relevant networks, and are recommended but not 
>> required.
>>
>> CHANGE PROPOSAL:
>>
>> "
>> As previously noted, the PHB implementation requires the QoS 
>resource 
>> request triggered from the end device (UNI interface) and the 
>> subscriber to be authenticated and authorized. Different mechanisms 
>> are available for conveying the QoS information and also for 
>> performing the authentication and authorization. This document does 
>> not mandate a specific protocol to be used.
>> "
>>
>> REASON: The discussion regarding NSIS vs. RSVP is irrelevant 
>for this 
>> document. The recommendation for RSVP is not necessary in order to 
>> accomplish the overall goal of this document.
>
>the problem is that you are leaving out the *critical* term of 
>capacity admission in your proposed text.  And yes, take that 
>out, and I have no qualms in removing references/text 
>concerning NSIS and RSVP.  But, capacity admission has to be 
>there...its part of the foundation for the draft in the first place.

That's in the previous paragraph. I believe that there is no reason to
repeat it again. 

>
>While the term QoS tends to imply the probable use of capacity 
>admission, its too broad a term with respect to how you choose 
>to use it above.  For instance, I can configure filters for a 
>CBQ router to alter the QoS for certain types of flow and thus 
>influence the QoS received by those flows, but that effort 
>does not necessarily deal with capacity admission.

That's true. Signaling the QoS parameters does not imply capacity
admission control. 
However, I believe it is covered by the previous paragraph already. 

>
>> 5.  Security Considerations
>>
>>    A major requirement of this service is effective use of a 
>signaling
>>    protocol such as RSVP, with the capabilities to identify its user
>>    either as an individual or as a member of some corporate entity, 
>> and
>>    assert a policy such as "routine" or "priority".
>>
>>    This capability, one has to believe, will be abused by script 
>> kiddies
>>    and others if the proof of identity is not adequately strong or if
>>    policies are written or implemented improperly by the carriers.   
>> This
>>    goes without saying, but this section is here for it to be said...
>>
>> A question: Is there really a (major) requirement to 
>identity the user 
>> as individual or as a member of some corporate entity? I would have 
>> said that there are authentication and authorization requirement but 
>> not necessarily regarding the membership.
>
>I don't have a strong opinion on this, so I suggest one of the 
>co- authors chime in on this.
>
>> 4.  IANA Considerations
>>
>>    This note requests that IANA assign a DSCP value to a second EF
>>    traffic class consistent with [RFC3246] and [RFC3247] in the
>>    "Differentiated Services Field Codepoints" registry.  It 
>implements
>>    the Telephony Service Class described in [RFC4594] at lower speeds
>>    and is included in the Real Time Treatment Aggregate [RFC5127] at
>>    higher speeds.  The recommended value for the code point 
>is 101100,
>>    paralleling the EF code point, which is 101110.  The code point
>>    should be referred to as VOICE-ADMIT.
>>
>>    This traffic class requires the use of capacity admission such as
>>    RSVP services together with AAA services at the User/Network
>>    Interface (UNI); the use of such services at the NNI is at the 
>> option
>>    of the interconnected networks.
>>
>> SUGGESTION: Delete last paragraph as it does not add anything beyond 
>> what was said in the document.
>
>let's not for now :-)

Then, I suggest to remove the RSVP part. 

Ciao
Hannes

>
>cheers,
>
>-ken
>
>