|
»
« Return to Thread: FWD: [Re: proposed charter]
Re: AW: AW: FWD: [Re: proposed charter]
by Paulo Mendes
::
Rate this Message:
Hi Hannes,
All the questions that you mention are some of the reasons to have a WG
looking at what do we need to operate a DiffServ network. Even if we
focus on protocols, as you did in your e-mail, all your questions show
that although we have a set of protocols available in IETF we still
don't know our to inter-operate them for a common goal. The control of
Diffserv networks, in this case.
About what comes first, protocols or service control, IMO a protocol is
only useful if we know why do we need it. Transporting data-control
packets among network devices serves the goal of controlling some
network functionality. In the case of DiffServ, it is not clear what
protocols (and what content semantic) do we need and how will they
interact to control DiffServ operations.
I see this as a very good opportunity to stress the cooperation between
different IETF WGs with a common goal in mind. So, DCPEL is all about
cooperation and not about competition between WGs.
Paulo
Tschofenig, Hannes wrote:
>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:nichols@...]
>>Gesendet: Donnerstag, 9. März 2006 16:56
>>An: Tschofenig, Hannes; dcpel@...
>>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
>>Dcpel@...
>>https://www1.ietf.org/mailman/listinfo/dcpel
>>
>>
>>
>
>_______________________________________________
>Dcpel mailing list
>Dcpel@...
>https://www1.ietf.org/mailman/listinfo/dcpel
>
>
>
_______________________________________________
Dcpel mailing list
Dcpel@...
https://www1.ietf.org/mailman/listinfo/dcpel
All the questions that you mention are some of the reasons to have a WG
looking at what do we need to operate a DiffServ network. Even if we
focus on protocols, as you did in your e-mail, all your questions show
that although we have a set of protocols available in IETF we still
don't know our to inter-operate them for a common goal. The control of
Diffserv networks, in this case.
About what comes first, protocols or service control, IMO a protocol is
only useful if we know why do we need it. Transporting data-control
packets among network devices serves the goal of controlling some
network functionality. In the case of DiffServ, it is not clear what
protocols (and what content semantic) do we need and how will they
interact to control DiffServ operations.
I see this as a very good opportunity to stress the cooperation between
different IETF WGs with a common goal in mind. So, DCPEL is all about
cooperation and not about competition between WGs.
Paulo
Tschofenig, Hannes wrote:
>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:nichols@...]
>>Gesendet: Donnerstag, 9. März 2006 16:56
>>An: Tschofenig, Hannes; dcpel@...
>>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
>>Dcpel@...
>>https://www1.ietf.org/mailman/listinfo/dcpel
>>
>>
>>
>
>_______________________________________________
>Dcpel mailing list
>Dcpel@...
>https://www1.ietf.org/mailman/listinfo/dcpel
>
>
>
_______________________________________________
Dcpel mailing list
Dcpel@...
https://www1.ietf.org/mailman/listinfo/dcpel
« Return to Thread: FWD: [Re: proposed charter]
| Free embeddable forum powered by Nabble | Forum Help |
