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

[ken carlberg <[e-mail]>]

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.

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.

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

cheers,

-ken