Subject: AW: New MPLS charter

From: Hummel Heinrich <[email-masked]>
Date: Fri, 1 Dec 2000 10:51:56 +0100

Georg,
  
you wrote"...we can define new ways of carrying labels where new kinds of link layers may emerge out of the Optical work".
Let me think in this direction:
Let me call all so far defined LSPs "User Plane LSPs" because they  transmit user data (in such a way that no transit-LSR will
evaluate the IP Header of the user data packets).
We may define as well "Control Plane LSPs": They should transmit only messages for establishing/terminating User Plane LSPs.
Hereby the "Control Plane" labels should only be used to determine the next hop( = replacement of the longest prefix match mechanism).
Each transit-LSR should evaluate the IP Header and even the entire
"Control Plane" packet =MPLS-message like RSVP-PATH or a CRLDP-LABEL_REQUEST,... 
Remains the question how and when to install the NHLFEs of the "Control Plane" labels: Well, BGP4, PIM, LDP-unsolicited
downstream may be used to install them.

The benefit: The establishing of User Plane LSPs by means of RSVP resp.  LDP-downstream-on-demand, can be done 
almost as fast as transmitting user data by the User Plane LSP.

Another goal:
Studying and specifying the case where a Control Plane LSP and any of its associated User Plane LSPs only share
the common endpoints but not the route between these endpoints.

What do you think ?

Heinrich Hummel
Siemens AG
[email-masked]

	--------------------------------------------------------------------- 
> Spencer -
> 
> The way I read that (and I would like to be wrong on this, but doubt
> that I am) is we can define new ways of carrying labels where new
> kinds of link layers may emerge out of the Optical work.  Also I don't
> really anticipate any need in that area, since we already have an
> encapsulation over PPP and PPP is likely to be defined over any thing
> that emerges out of the optical work.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

---

From: Shahram Davari <[email-masked]>
Date: Fri, 1 Dec 2000 05:14:31 -0800

Hummel,

What is a control-plane label? Control-plane messages are not sent as labeled packets, rather they are sent as IP packets.

Yours,
-Shahram

> -----Original Message-----
> From: Hummel Heinrich [mailto:[email-masked]]
> Sent: Friday, December 01, 2000 4:52 AM
> To: 'George Swallow'; Dawkins, Spencer
> Cc: [email-masked]
> Subject: AW: New MPLS charter 
> 
> 
> Georg,
>   
> you wrote"...we can define new ways of carrying labels where 
> new kinds of link layers may emerge out of the Optical work".
> Let me call all so far defined LSPs "User Plane LSPs" because 
> they  transmit user data (in such a way that no transit-LSR will
> We may define as well "Control Plane LSPs": They should 
> transmit only messages for establishing/terminating User Plane LSPs.
> Hereby the "Control Plane" labels should only be used to 
> determine the next hop( = replacement of the longest prefix 
> match mechanism).
> Remains the question how and when to install the NHLFEs of 
> the "Control Plane" labels: Well, BGP4, PIM, LDP-unsolicited
> The benefit: The establishing of User Plane LSPs by means of 
> RSVP resp.  LDP-downstream-on-demand, can be done 
> Studying and specifying the case where a Control Plane LSP 
> and any of its associated User Plane LSPs only share

---

From: Hummel Heinrich <[email-masked]>
Date: Fri, 1 Dec 2000 14:40:14 +0100

Shahram,
A label that pilots the packet (which is e.g. a Label_Request message) to the next hop router rather than by longest prefix match.

To make it clear: 

Such kind of label hasn't been specified by any MPLS protocol yet ! 
You are absolutely right: So far, Control-plane messages are not sent as labeled packets, rather they are sent as IP packets.

Yours,
Heinrich 
> -----Urspr> üngliche Nachricht-----
> Von:	Shahram Davari [SMTP:[email-masked]]
> Gesendet am:	Freitag, 1. Dezember 2000 14:15
> An:	'Hummel Heinrich'; 'George Swallow'; Dawkins, Spencer
> Cc:	[email-masked]
> Betreff:	RE: New MPLS charter 
> 
> Hummel,
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 1 Dec 2000 05:50:25 -0800

Hummel,

What is wrong with the longest prefix match? besides how do you setup the labels for the control plane?

Yours,
-Shahram

> Sent: Friday, December 01, 2000 8:40 AM
> To: Shahram Davari; Hummel Heinrich; 'George Swallow'; 
> Dawkins, Spencer
> Cc: [email-masked]
> A label that pilots the packet (which is e.g. a Label_Request 
> message) to the next hop router rather than by longest prefix match.
> 
> To make it clear: 
> 
> You are absolutely right: So far, Control-plane messages are 
> not sent as labeled packets, rather they are sent as IP packets.
> 
> 
> Yours,
> Heinrich 
> > What is a control-plane label? Control-plane messages are 
> not sent as labeled packets, rather they are sent as IP packets.
> > 
> > Yours,
> > -Shahram
> >

---

From: Ben Mack-Crane <[email-masked]>
Date: Fri, 01 Dec 2000 08:05:58 -0600

Bora,

A proposed charter that is under consideration has been posted on the
IETF Announcement mailing list.  I have copied the message below (cut
and paste from the archive).

Regards,
Ben

WG Review: Common Control and Measurement Planes (coma)

     To: IETF-Announce: ; 
     Subject: WG Review: Common Control and Measurement Planes (coma) 
     From: The IESG <[email-masked]> 
     Date: Mon, 20 Nov 2000 15:53:47 -0500 
     cc: [email-masked] 
     Reply-to: [email-masked] 
     Sender: [email-masked] 

A new IETF working group has been proposed in the IETF.
The IESG has not made any determination as yet. 

The following Description was submitted, and is provided for
informational purposes only:

Common Control and Measurement Planes (coma)
--------------------------------------------

Current Status: Proposed Working Group

Organizational Overview

The CoMa working group coordinates the work within the IETF towards
defining a common control plane and a separate common measurement
plane for ISP and SP core tunnel technologies.   The purpose of
the group, besides specifying the common control and the common
measurement protocols, is to ensure that inputs and requirements
from the MPLS, IPO, PPVPN and TE working groups (and future ones that
may be formed on related topics) are completely taken into account, and
that those working groups (and future related others) produce results
that make best, cleanest use of the commonalities in control and the
commonalities in measurement.

Description of the Working Group:

Over the last few years the need for common control and status
protocols for representing and manipulating layer 1 and 2 resources
has become more urgent. Particularly pressing is the need to
accommodate switched optical networks where the intermediate switches,
while controllable via IP-based protocols, are transparent above the
physical layer to the data traffic flowing through them. From a
control perspective, there is the need to perform such network
engineering functions as traffic engineering, provisioning path
protection and restoration, and path preemption in a common way across
both physical and tunneled technologies.

Common measurement is Independent of the actual control regime.  It
requires the ability to report on the status and properties of he
subcomponent parts of a network (e.g.  lambdas, fibers, PVCs, switch
ports, optical cross connects) to elements such as external servers,
the routing plane, or a database, and to report on the properties and
liveness status of paths currently instantiated.

This working group will tackle the problem of creating both the common
control and common measurement planes for tunnels and phyical paths.
It will deal with the technology-independent control and measurement
aspects of traffic engineering, protection/restoration, and tunnel
operation. It will define protocol support for resource sharing and
preemption. It will ensure that the control and measurement protocols
are capable of operation both within and across administrative 
boundaries.
Both intra-domain and inter-domain scopes are important, and CoMa will
design with both scopes in mind, however the working group may determine
that intra-domain protocols require faster development than those that
cross administrative boundaries.

Specific tasks for the working group include the following:

- Define a single control protocol and a single measurement
protocol such that they are independent of each other.
This allows the measurement protocol to be used by multiple
consumers, including layer 3 routing protocols, centralized path
computation servers, and passive path and resource monitoring devices,
among others. Similarly, it allows the control protocol to use
knowledge obtained by means other than the measurement
protocol. Existing IETF protocols should be used as the basis
for both protocols to every extent possible.

- Define the control protocol and the measurement protocol such that
they support multiple tunnel and physical path technologies (e.g. O-O
and O-E-O optical switches, MPLS, GRE) using input from
technology-specific working groups such as MPLS, IPO, etc.

- Define and incorporate into the control and measurement protocols
those network resource properties that are common across
technologies. For properties which are technology-specific
(e.g. wavelength-dependent dispersion of fiber paths) give guidance to
the technology-specific group(s) for how to incorporate their
parameters into the protocols.

- Define how the properties of network resources gathered by the
measurement protocol can be distributed in layer 3 routing protocols,
such as OSPF and ISIS. This includes recommended methods for
aggregation and summarization of data as needed for
scalability.

- Define the relationship between layer 3 routing protocols
and the common control protocol for establishing and maintaining
paths.

- Using input from the TE working group, ensure that the control and
measurement protocols provide both the information and the control
functions adequate to support the traffic provisioning and engineering
operations of service providers.
- Ensure that multi-layer path protection and restoration functions
are achievable using the defined control and measurement protocols,
either separately or in combination.

- Define protocol support for path measurement and liveness
monitoring, including considerations of what the currency of the
measure data needs to be, how much overhead can be tolerated for such
measurement, and how the measurements impact various control
mechanisms (including, but not limited to the common control
protocol).

Working Group Organization

In doing this work, the WG will work closely with the following other
WGs and constituencies:

- Engage SPs to further refine service requirements from a Service
Provider perspective and to ensure that such a protocol can work
reasonably with existing management and provisioning systems.

- Jointly develop any enhancements or modifications to the traffic
engineering aspects of control plane operation with the TE working
group

- Jointly progress any IGP metrics/parameters with the ISIS and
OSPF WGs

- Accommodate technology specific input from the IPO WG, and
other tunnel technologies as needed (e.g. GRE).

In addition, The CoMA WG should ensure good communication with other
standards bodies such as the ITU-T, and interoperability forums such
as the OIF and ODSI engaged in IP/optical control plane work.  But
as is generally true with IETF working groups, formal liaison
planning will be done by the IAB, and the communications flow about
technical work will be on a technical and individual contributor
basis otherwise.

[email-masked] wrote:
> 
> So is there a charter for the new COMA working group, or a mailing list.
> 
> Bora
> 
> George Swallow wrote:
> 
> > Spencer -
> >

---

From: Hummel Heinrich <[email-masked]>
Date: Fri, 1 Dec 2000 15:20:40 +0100

Shahram,
Well why was label switching invented in the first place?
Obviously, longest prefix match is slower than looking up the next interface and the next label based on an incoming label.

Certainly, the profit is bigger when thousands of  user packets are forwarded by label switching compared with one single "Label-Request"- packet being label-switched.
However, there may be good reasons for fast path establishment as well:(optical !) path restoration, path rerouting,etc.

I did not say that the existing way, i.e. forwarding an LSP-establishment message like a classic IP packet, shall be replaced, but there should be space 
for both methods !

	I mentioned several protocols where to setup labels for the control plane: Particularly BGP4 and LDP(unsolicited downstream mode).
	Maybe OSPF too. Of course, it would take some study to find out the details and also   how to differentiate these new animals from the existing ones:-)

	Heinrich

> > > -----Urspr> > üngliche Nachricht-----
> > > > almost as fast as transmitting user data by the User Plane LSP.> 
> > > > 
> > > > Another goal:

---

From: Hummel Heinrich <[email-masked]>
Date: Fri, 1 Dec 2000 16:07:16 +0100

>    Shahram,
>  
> Although at the beginning of MPLS development it was believed that longest prefix match is slow and label switching will improve it, but future developments showed otherwise. In fact very good algorithms became available that could do a maximum of 3 lookups to do the longest prefix match. So the benefits of MPLS with regard to fast lookup diminished.
	 
	Good point. And I also believe that the existing label transport within BGP4 is an excellent move in the same direction that  I am thinking.
	 
	Give me some time to think about other good reasons. Routing is a large area, maybe anybody else find new reasons to do so !?  :-)

>  
> > 	I mentioned several protocols where to setup labels for 
> > the control plane: Particularly BGP4 and LDP(unsolicited 
> > downstream mode).
> 
> But you still need IP to transport BGP, LDP, ..., don't you?
	  
	Sure.

> Yours, and have a good weekend
> 
	  Heinrich

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 4 Dec 2000 15:40:17 +0100

> 	   Shahram,
		Maybe we both will learn more good reasons in the Forwarding and Control Element Separation BOF (forces)

		Heinrich