Subject: RE: [Dcpel] Dcpel BoF support

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Fri, 28 Oct 2005 11:27:52 +0200

Dear All,  

Dear all, as I understand the main goal of the working group would be to identify and define elements for DiffServ-based resource manager concept.

I think that such concept should address inter-domain signaling as well. Note that there is an NSIS a proposal for path-decoupled signaling. If it gets through, NSIS could be used as protocol between resource managers. Anyway it should be avoided that IETF develops two protocols parallel for the same purpose. 

Best regards, Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 27, 2005 7:19 PM
> To: [email-masked]
> Subject: Re: [Dcpel] Dcpel BoF support
> 
> 
> Paulo Mendes wrote:
> ...
> > 
> > Concerning  the charter, I think that it will be more efficient to
> > divide the effort in inter- and intra-domain. The main reason, in my
> > opinion is that decoupling inter- and intra- this will bring more
> > flexibility in end-to-end operations. Modularity is always a good
> > principle.
> 
> [Kathie]I believe division is the way to go, but I think we 
> need to keep
> in mind that we have to make the step from intra- to inter-. This
> hasn't seemed all that divergent in the work I've done, but I'm
> interested to see others' approaches and concerns. For example,
> I think when one constructs in interior control plane, it is
> necessary to think about what information  you are willing to
> expose to the outside, what you will send and what you will
> accept. So I think that sets you up for the inter- step.
> 
> <The "you" below refers to Olivier, not to me.>
> > 
> > You say that your focus in not on DiffServ to enforce QoS in the
> > network, but on the definition of a Resource Manager 
> framework. Good,
> > but this Resource Management framework can still be defined with two
> > modules for inter- and intra-domain, connected by a network 
> interface.
> > But, in what concerns the intra-domain resource control, I 
> don't know
> > why shouldn't we focus on DiffServ. First, the DiffServ 
> model is clearly
> > lacking a control plane; second, other QoS enforcement 
> mechanisms, such
> > as MPLS, already define how resources may be controlled. Moreover, I
> > still think that DiffServ as a lot of potential, not only to support
> > qualitative traffic, but also quantitative one.
> 
> [Kathie] I really feel the focus should be on a diffserv control plane
> for exactly your reasons. I think people like Olivier can perhaps
> try to keep us on track not to conflict with other control plane
> actions.
> <again, the "you" below is Olivier, I think.>
> > 
> > Another question is related to the 'topology acquisition' item. This
> > means that you think that the control of resources within a DiffServ
> > network should be centralized in a "resource manager", 
> which will then
> > need to collect topology information? Since a PDB is 
> already defined in
> > a distributed way, why not allow the control of resources to be
> > distributed, with most of the operations being located at the edges?
> > This distributed approach brings the benefits of higher 
> robustness and
> > perhaps performance.
> 
> Hmm, I don't think topology acquisition necessarily means 
> "centralized".
> After all, routing protocols construct a topology and are distributed.
> I've been bothered by the characterization of bandwidth/resource
> manager style solutions as "centralized" where I would characterize
> them as "network-wide". I think of a diffserv control plane as being
> decoupled from the forwarding path but having the network 
> wide awareness
> needed to enforce a PDB (so it sounds like we agree here). The actual
> entity or entities that implement this can be as "centralized" or
> "distributed" as needed.
> > 
> > In what concerns the other standardization efforts, I would 
> say that it
> > would help a lot this BoF, if we had a brief document 
> characterizing the
> > differences between all these approaches to see where this 
> BoF would fit.
> 
> Okay. Do you mean centralized vs distributed approaches to diffserv
> control plane? I would somewhat like to see if we can do something
> that can include all of that range, but perhaps that's not possible.
> 
> 	Kathie
> 
> 
> _______________________________________________
> Dcpel mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dcpel
> 

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