Subject: [Dcpel] Re: [e2e] FYI: A Proposed IETF BoF on Diff-Serv Control Plane

From: Paulo Mendes <[email-masked]>
Date: Fri, 21 Oct 2005 13:34:01 +0200

Hello,

I'm quite interested in this BOF. Actually, for a long time that I was expecting a BOF like this to show up. This because it is perfectly synchronized with the work that I'm currently doing at the NTT DoCoMo laboratories in Europe. Currently, we are working on the following topics:
- Dynamic control of inter-domain QoS with local configuration of PDBs:
   - Standard Information model
   - Standard interface
   - Standard protocol for local configuration of classes
- Distributed control of intra-domain QoS with admission control and dynamic allocation of BW to different classes.

I enumerated these two topic in a clear separation between inter-domain and intra-domain. This because the requirements are clearly different. For instance, in what concerns signaling, while inter-domain must be done at the network level, and a protocol much simpler than NSIS may be used, intra-domain control of classes resources should be done in the data path from ingress to egress.

It seems that for now there is only Nichols's et al. ID about a strawman description of components. If there is already a stable idea of what this control plane must, should and may provide, I agree that the next step may be the classification of existing solutions and identification of missing functionalities. Otherwise, it is better to clearly identify the problem statement, and a set or requirements and assumptions.

So, I'm available to contribute to the following actions:
- Classification of requirements and assumptions for the control of DiffServ networks
- Specification of control elements/protocols (which should all have a good security assurance :) )

I could also help in the shape the BoF proposal, if still needed, but unfortunately, due to other travel appointments, I cannot attend the Vancouver meeting.

Cheers,
Paulo Mendes

>>Posted at the request of Bob Braden:
>>
>>----
>>
>>A Proposed IETF BoF on Diff-Serv Control Plane
>>
>>---------------------------------------------------------------
>>
>>We've been working toward a possible IETF BoF on diffserv 
>>control plane
>>elements to be under the Operations and Management Area. Our 
>>in-progress
>>Background and Goals for the BoF:
>>
>>It's been some time since the Diffserv forwarding path elements were
>>standardized. At that time, the approach was to get the mechanisms
>>deployed in routers so that approaches to service creation and control
>>plane could be attempted. Before closing, the Diffserv WG defined the
>>concept of Per-Domain Behaviors (PDBs) in RFC 3086, but left the
>>approach to controling PDBs open.
>>
>>Now Diffserv forwarding elements are available in most routers and are
>>in use to create services in some networks. A variety of 
>>approaches are
>>being used for control and management of Diffserv but there appears to
>>be some commonality. A possible path for IETF work is to enumerate and
>>classify the common elements and to work toward some best common
>>practices. Additionally, it may be useful to present 
>>specifications for
>>a range of diffserv control plane elements using common interfaces.
>>
>>The major issues to deploying Diffserv-based services are primarily
>>operational. The deployment must be cost-effective, be secured against
>>vulnerabilities and not become a vehicle for denial of 
>>service attacks.
>>Standardization should result in existing toolsets being 
>>either expanded
>>to cover more needed functionality or to interact with other tools. A
>>standardization effort should cover how to secure the architecture to
>>mitigate vulnerabilities. Standards for a control plane QoS agent for
>>routers may be useful. A desired outcome of IETF efforts is to make
>>multiple products available to network operators, obviating 
>>the time and
>>personnel expense of individual solutions. The end goal is to enable
>>more services, both for network customers and for control of the
>>network, without taxing personnel.
>>
>>The starting point for a BoF is to look at what's out there, determine
>>if there is indeed some uniformity of approach useful as a starting
>>point, and determine what's missing.
>>
>>The intial focus would be the intradomain control plane moving to
>>interdomain or AS under same provider and finally to interprovider or
>>interoperator.
>>
>>------------------------------------------------------------------
>>
>>The entire in-progress proposal for the BoF can be viewed at
>>www.pollere.com under Resources, then Current Work.
>>
>>If you are interested in helping to further shape the proposal, please
>>sign up for the email list [email-masked] through
>>www1.ietf.org/mailman/listinfo/dcpel and comment on the list.
>>
>>	thanks,
>>		Kathie Nichols
>>		Scott Bradner
>>
>>    
>>
>
>  
>

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

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 24 Oct 2005 15:41:18 -0700

Paulo Mendes wrote:
> Hello,
> 
> I'm quite interested in this BOF. Actually, for a long time that I was
> expecting a BOF like this to show up. This because it is perfectly
> synchronized with the work that I'm currently doing at the NTT DoCoMo
> laboratories in Europe. Currently, we are working on the following topics:
> - Distributed control of intra-domain QoS with admission control and
> dynamic allocation of BW to different classes.
> 
> I enumerated these two topic in a clear separation between inter-domain
> and intra-domain. This because the requirements are clearly different.
> For instance, in what concerns signaling, while inter-domain must be
> done at the network level, and a protocol much simpler than NSIS may be
> used, intra-domain control of classes resources should be done in the
> data path from ingress to egress.

That has been our thinking also. And I think it makes sense to seek
a charter that is limited to intra-domain at first. Many WGs
(including Diffserv) recharter when it is time for new work items
and that's a nice way to keep focus.

> 
> It seems that for now there is only Nichols's et al. ID about a strawman
> description of components. If there is already a stable idea of what
> this control plane must, should and may provide, I agree that the next
> step may be the classification of existing solutions and identification
> of missing functionalities. Otherwise, it is better to clearly identify
> the problem statement, and a set or requirements and assumptions.

I would welcome your input on any of these items. We put out a
strawman to give something common to talk about (even if it is
just to disagree with it. If you would like to write a brief
draft of a proposed problem statement, we could discuss that
on the list and at Vancouver. So, we have the possibility of
using the COPS RFCs as a basis for a diffserv control plane,
we have the option of looking at some solution approaches to
see if there is a stable idea of the control plane, and
we have the option of writing a problem statement.
> I could also help in the shape the BoF proposal, if still needed, but
> unfortunately, due to other travel appointments, I cannot attend the
> Vancouver meeting.
> 

Certainly shaping a proposal for a WG charter is still needed. This
can be done through email.

	regards,
		Kathie Nichols

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 26 Oct 2005 12:39:08 +0200

Hi Kathleen,

>and that's a nice way to keep focus.
I understand your reason to focus on intra-domain but, IMHO I think it 
is very important to also keep in mind the inter-domain aspect. I would 
propose to keep in the charter a sentence which clearly say that the WG 
will take into account the inter-domain and build a 
framework/architecture in this perspective. So, the result from the WG 
could be easely extend to inter-domain in a second step.

>we have the option of writing a problem statement.
I take the opportunity to give my understanding about COPS. I think that 
COPS is more devoted to apply policy to a given set of device rather 
than building a control Plane. In fact, the Dcpel could used COPS to 
enforce QoS in the network and IMHO is placed on top of PDP since it 
facilitate the PDP configuration. i.e. that it is not solved in COPS is 
how/when/with which information an operator could easely fullfill the 
PIB in a PDP.

>can be done through email.
Regards,

Olivier

-- 
Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           | mailto:[email-masked]
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85

---

From: Paulo Mendes <[email-masked]>
Date: Thu, 27 Oct 2005 13:37:31 +0200

Hi Kathleen,

>and that's a nice way to keep focus.
[Paulo] I agree. We can do this is two ways: a) create a charter only 
for intra-domain issues, keeping in mind that the charter may be changed 
latter to include inter-domain issues; b) he create a charter 
encompassing intra- and inter- domain issues, but we define a clear work 
plan, which should give higher priority to intra-domain issues. I would 
prefer the option b), because this will make the WG stronger, since we 
aim to provide the needed E2E solution. And in the end is this that 
matters. If you follow option a), we are leaving behind the major reason 
not to have QoS deployed in the Internet, which is the lack of 
inter-domain control.
I'm a little afraid that if we don't include the inter-domain control in 
our list of priorities, it may happen that we end up again with a 
half-solution: control of Diffserv networks but still no end-to-end QoS.

>we have the option of writing a problem statement.
I would very much like to contribute to this problem statement draft, 
since it will clarify our goals. If we do this, can you present the 
draft in Vancouver? (like I said in my last email, unfortunately I 
cannot attend the IETF meeting in Vancouver).

>can be done through email.
Cheers
Paulo

---

From: Paulo Mendes <[email-masked]>
Date: Thu, 27 Oct 2005 13:37:46 +0200

Hi there,

some comments inline...

Olivier Dugeon wrote:

> is very important to also keep in mind the inter-domain aspect. I 
> would propose to keep in the charter a sentence which clearly say that 
> the WG will take into account the inter-domain and build a 
> I take the opportunity to give my understanding about COPS. I think 
> that COPS is more devoted to apply policy to a given set of device 
> rather than building a control Plane. In fact, the Dcpel could used 
> COPS to enforce QoS in the network and IMHO is placed on top of PDP 
> since it facilitate the PDP configuration. i.e. that it is not solved 
> in COPS is how/when/with which information an operator could easely 
> fullfill the PIB in a PDP.

[Paulo] Keeping in mind a modular distinction between inter- and 
intra-domain, I would say that based on a set of available inter-domain 
QoS agreements, the PDP, which control the QoS agreements, may use COPS 
to enforce QoS in the network, as you say. But we must see what do you 
mean by "enforcing the QoS in the network". IMHO there are two options: 
a) a centralized one, in which the PDP uses COPS to configure all the 
needed routers; b) a decentralized one, in which the PDP used COPS to 
configure the ingress PEP, and to inform the PEP about the PDB that 
needs to be setup. Based on this information the PEP uses an 
intra-domain signaling protocol to perform class configuration until the 
required egress point. This signaling may be based on a NSIS protocol.

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 27 Oct 2005 10:21:12 -0700

Paulo Mendes wrote:
...
> cannot attend the IETF meeting in Vancouver).

If you produce something we can put out on the list (it can go into
the I-D repository later) and we are given sufficient time, I would
be happy to put it on the agenda for discussion. Perhaps some of us
can meet separately if there is insufficient time. And we can always
have list discussion.

	Kathie

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 28 Oct 2005 18:00:12 +0200

Hi Kathleen and all,

I would like to give it a try, and write a I-D focusing on the problem 
statement. However, due to traveling, I can only write this I-D on the 
3rd-4th of November. I can send it then to the mailing list. I hope this 
is not too late to allow us to discuss it in the mailing list, before 
Vancouver.

Paulo