AW: AW: [Dcpel] FWD: [Re: proposed charter]

["Tschofenig, Hannes" <[e-mail]>]

Hi Kathie, 

your mail points to an aspect that a number of us have never really understood. 
I think we have a terminology problem here. 

Just as an example, let us take a look at Figure 1 of <draft-vandenberghe-dcpel-basics-00.txt>:

                    +-DCP-----------------------------+
                    |                                 |
                    | +---------------+  +-----+      |
                    | |Domain Policies|  | AAA |      |
                    | +--------||-----+  +-----+      |
                    |          ||          ||         |
                    |    +-----||----------|+         |
   QoS Announce(*) <=====|                  |=========> QoS Announce (*)
   QoS Request  ========>|                  |=========> QoS Request
   QoS Response <========|        DCP       |<========= QoS Response
   QoS Query(*) ========>|                  |=========> QoS Query(*)
   QoS Status   <========|                  |<========= QoS Status
                    |    +----||------------+         |
                    |         ||          ||          |
                    | +-------||------+ +-||--------+ |
                    | | Enforcement   | | Monitoring| |
                    | +---------------+ +-----------+ |
                    |                                 |
                    +---------------------------------+

A few protocol interactions that come to my mind when I see this figure are: 

a) How does the AAA infrastructure interact with the DCP node? 
b) Isn't a protocol required in order to provide the interaction between different DCP nodes? (e.g., for QoS Announce, Request, Response, Query, Status)?
c) How does the DCP node communicate with the enforcement (points)?
d) How does the interaction between DCP and the monitoring entities looks like? 
e) Where do the Domain Policies come from? 

For (a) you mention "access to the AAA information". This might be RADIUS or Diameter since this stuff is used today. 
For (b) you mention "external protocol/mechanism sends a QoS Query, .... to the DCP" 
For (c) you mention COPS, Netconf, SNMP 
For (d) you mention "needs access to a wide range of information about the operational conditions of its network."
For (e) you mention "A DCP must either contain these or have access to them, perhaps a combination." 

The draft also talks about other protocols like SIP and NSIS.

Having briefly looked at these aspects of your draft please explain what you mean by:

* "... infrastructure that is capable of realizing services on an IP network before we worry overly much about what is being sent."

* "Particularly since signaling is not required for all services."

(Note that the term 'service' is not really well defined in the IETF nor in any other organization.)

* "It seems
> to be all about signaling. In my opinion, this has been a big
> problem in the QoS area in general and particularly at the IETF.
> That is, spending time talking about what information is going to
> be sent around and in what sort of containers rather than how to
> manage and control IP differentiated services."

If you do not have these protocols and if you don't worry about the content that is sent around (with the associated semantic) then it might be a 'little bit difficult' to dynamically manage and control QoS.

What term do you use for this dynamic information exchange? 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Kathleen Nichols [mailto:[e-mail]] 
> Gesendet: Donnerstag, 9. März 2006 16:56
> An: Tschofenig, Hannes; [e-mail]
> Betreff: Re: AW: [Dcpel] FWD: [Re: proposed charter]
> 
> 
> So, I really must reply, in brief, to Hannes's email. It seems
> to be all about signaling. In my opinion, this has been a big
> problem in the QoS area in general and particularly at the IETF.
> That is, spending time talking about what information is going to
> be sent around and in what sort of containers rather than how to
> manage and control IP differentiated services. If the right
> information is being sent, then a useful control and management
> structure should be able to use it. But it seems like we need to
> have an infrastructure that is capable of realizing services on
> an IP network before we worry overly much about what is being
> sent. Particularly since signaling is not required for all
> services.
> 
> 	Kathie
> 
> _______________________________________________
> Dcpel mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dcpel
> 

_______________________________________________
Dcpel mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dcpel