Subject: Draft of revised charter

From: George Swallow <[email-masked]>
Date: Wed, 19 Jan 2000 15:27:16 -0500

Folks,

Attached is a draft of the revised MPLS charter.  The goals and
milestones section is far from complete.  I've listed a few items
where I know that there are people committed to doing the work.
Please send ideas for further goals and other comments to the list.

Thanks,

George & Vijay

======================================================================

Multiprotocol Label Switching (mpls) Charter

Problem Statement:

Label switching in conjunction with network layer routing has emerged
as an important new technology.  It is actively being applied to
applications such as traffic engineering and virtual private networks.
Among the problems this technology is expected to address are the
following:

1.  Greater flexibility in delivering routing services

Using labels to identify particular traffic which are to receive
special services, e.g. QoS.

Using labels to provide forwarding along an explicit path different
from the one constructed by destination-based forwarding.

2.  Scalability of network layer routing

Using labels as a means to aggregate forwarding information, while
working in the presence of routing hierarchies.

3.  Simplify integration of routers with cell switching based
technologies

a) making cell switches behave as peers to routers (thus reducing
the number of routing peers that a  router has to maintain),

b) by making information about physical topology available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and management
procedures.

4.  Simplify integration of routers with optical cross-connect based
technologies

a) making optical cross connects behave as peers to routers (thus
reducing the number of routing peers that a router has to maintain),

b) by making information about physical topology available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and management
procedures.

High Level Requirements

1.  The solution should be general with respect to data link
technologies. Specific optimizations for particular media will be
considered.

2.  The solution must be compatible with existing internetwork
technologies and routing protocols.

3.  The solution should support a wide range of forwarding
granularities associated with a given label, from a single
application flow to a group of topologically related destinations.

4.  The solution should support operations, administration, and
maintenance facilities at least as extensive as those supported in
IP networks.

5.  The solution should provide stable routing.  The protocols defined
by MPLS must provide protocol mechanism(s) to either prevent the
formation of loops and/or contain the amount of (networking) resources
that could be consumed due to the presence of such loops.

6.  The solution should be very scalable.  Scalability issues will be
considered and analyzed.

Charter Statement:

The working group is responsible for standardizing a base technology
for using label switching in conjunction with network layer routing
and for the implementation of that technology over various link level
technologies, which may include Packet-over-Sonet, Frame Relay, ATM,
Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,...

This includes procedures and protocols for the distribution of labels
between routers, encapsulations, multicast considerations, and the use
of labels to support higher layer resource reservation and QoS
mechanisms.

The working group will also specify a control plane for optical cross
connects.  In this environment specific wave lengths or Lambdas are
used instead of labels.

Objectives:

1.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support unicast destination-based
routing.

2.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support multicast routing.

3.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support hierarchy of routing knowledge
(e.g., complete segregation of intra and inter-domain routing).

4.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support explicit paths in support of
applications such as Traffic Engineering.

5.  Specify standard protocols and procedures to support the fast
recovery of Label Switched Paths.

6.  Specify extensions to the protocols and procedures used for
signaling explicit routes and to effect fast recovery of LSPs
for use in Optical Cross Connects.  

7.  Specify standard procedures of carrying label information over
various link level technologies including ATM.

8.  Define the use of Differentiated and Integrated Services in an MPLS
environment.

9.  Specify standard protocols and procedures to support operations,
administration, and maintenance facilities.

Coordination:

The working group will coordinate its activities with other working
groups as appropriate.  For specific technologies, the WG will
cooperate with the appropriate standards bodies such as OIF, ITU-T, 
ANSI, etc. 

Goals and Milestones:

Mar 00 - Produce a document which defines support of Differentiated
         Services (Diff-Serv) over Multi-Protocol Label Switching 
         (MPLS) networks (Standards Track).

Aug 00 - Produce a document which defines operation with RSVP for 
         unicast destinations. (Standards Track).

Dec 00 - Produce specifications for a MPLS control plane for optical 
         cross-connects (Standards Track).

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 21 Jan 2000 13:46:35 -0500

George,

>8.  Define the use of Differentiated and Integrated Services in an MPLS

I suggest the above objective be changed to "aggregated QoS", as discussed 
in November.  From the minutes:

"Vijay asked if people are comfortable that the only QoS being
discussed here is the DiffServ model.  This question served to
generate quite a bit of discussion.  Bruce Davies said that he would
like to see IntServ semantics included, as well as the explicit
congestion notification work.  Joel Halpern said that there are
several issues that have gotten confused.  He pointed out that all of
the proposals we have looked at with interest aggregate QoS for
scaling purposes.  For the purposes of the charter, this could be
listed as "based on aggregated QoS", which is more general than just
DiffServ.  Vijay withdrew his question."

On a different charter topic, I think the charter should specifically 
mention that the WG plans to liaise with other standards bodies, especially 
in the optical area, such as OIF, ITU-T, ANSI, ODSI, etc..  This would 
prevent unnecessary duplication of effort, have the IETF output reviewed by 
other bodies that have the appropriate expertise, and prevent unintended 
interactions with other existing and developing standards.  Optical is a 
new area for the IETF and it would be pure hubris for us to work in a 
vacuum, or just assume that the necessary interactions will take place 
automatically.

Thanks,
Andy

---

From: Chip Sharp <[email-masked]>
Date: Fri, 21 Jan 2000 13:57:11 -0500

At 01:46 PM 1/21/00 -0500, Andrew G. Malis wrote:
>mention that the WG plans to liaise with other standards bodies, 
>especially in the optical area, such as OIF, ITU-T, ANSI, ODSI, 
>etc..  This would prevent unnecessary duplication of effort, have the IETF 
>output reviewed by other bodies that have the appropriate expertise, and 
>prevent unintended interactions with other existing and developing 
>standards.  Optical is a new area for the IETF and it would be pure hubris 
>for us to work in a vacuum, or just assume that the necessary interactions 
>will take place automatically.

I believe that ITU-T should also liaise to IETF mpls before embarking on 
new adventures in MPLS.
:-)

BTW, ITU has assigned a number to I.ipatm:  Y.1310
It is scheduled for approval in March.
Chip

>Andy

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

---

From: George Swallow <[email-masked]>
Date: Fri, 21 Jan 2000 14:20:02 -0500

Andy

> DiffServ.  Vijay withdrew his question."

While I agree that most of what has been done so far is aggregated
QoS, I see no need to limit the charter.  We do have a albeit expired
draft on MPLS and RSVP.  I expect that effort to be revived.
 
> vacuum, or just assume that the necessary interactions will take place 

The charter already mentions all the above bodies, with the exception
of teh ODSI (is the ODSI formally charter or still in the works?).
According to Brian Carpenter the IETF prefers informal liaisons.
Further it's actually up to the IAB to establish a formal one.  

So I think the wording in the charter supports what we need to do be
it formal or informal.  To state that we're going to establish a
formal liaison would inappropriate as that's in the purve of the IAB.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Eric Gray <[email-masked]>
Date: Fri, 21 Jan 2000 14:24:24 -0500

Chip,

	This may be a bit of a stretch.  I.ipatm does
not attempt to define how MPLS works, nor does it try
to define a new way to do what MPLS does.

	Asking one organization to liaise with another
before selecting a protocol to use for its purposes is
a little like asking a carpenter to liaise with a tool
manufacturer before selecting a hammer.

You wrote:
> >...

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 21 Jan 2000 11:34:22 -0800

George Swallow wrote:
	[..]
> draft on MPLS and RSVP.  I expect that effort to be revived.

"aggregated QoS" in no way limits the charter. on the contrary,
"Differentiated and Integrated Services" limits the charter to
the models conventionally understood to be meant by those two
terms. (even a per-flow intserv model can be viewed as aggregated QoS
from the perspective of the application level)

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research Silicon Valley

---

From: Eric Gray <[email-masked]>
Date: Fri, 21 Jan 2000 14:37:59 -0500

> draft on MPLS and RSVP.  I expect that effort to be revived.

You would be in a position to know, but I was under the
impression that RSVP-Tunnels pretty much covers the bases
for RSVP-MPLS once you realize that the messages do not
have to carry an explicit route object.  I thought this 
point had been made once or twice already.

Or did I miss something?

...

---

From: George Swallow <[email-masked]>
Date: Fri, 21 Jan 2000 14:44:05 -0500

Eric -

> point had been made once or twice already.

This is pretty much the case for unicast traffic.  Most of the
technical guts of the RSVP draft was moved to the tunnels draft since
the former was hung up on some multicast issues.

There are a few issues that should be addressed for the unicast case.
WF comes to mind.  I'm not sure if there are others.

...George

---

From: Eric Gray <[email-masked]>
Date: Fri, 21 Jan 2000 15:11:51 -0500

George,

	Ah!  Thanks for the clarification.

	Then we can expect the next version of MPLS-RSVP
to have solved the issues with multicast label switching
with QoS, as well as some unresolved unicast issues? :-)

---

From: Chip Sharp <[email-masked]>
Date: Fri, 21 Jan 2000 15:02:05 -0500

I was referring to any work concerning MPLS that might be initiated in ITU, 
whether in SG13, SG11 or SG7.  For example, if the ITU initiates work in 
the optical area and decides to use MPLS, I hope they will liaise with IETF.

Chip

---

From: Eric Gray <[email-masked]>
Date: Fri, 21 Jan 2000 15:11:51 -0500

George,

---

From: "Philip Matthews" <[email-masked]>
Date: Tue, 25 Jan 2000 08:48:12 -0500

[Resend, as it seems that the original message did not
make it to the list for some reason.]
----
I have a question about the proposed charter revision.
Should the new charter contain some words about the
division of work between the MPLS WG and the TE WG?

At the Washington meeting, there were some drafts that
were presented to both the MPLS and TE groups, while other
drafts were presented to what I felt was the wrong group.

Perhaps some words in the charter that state that certain
areas of investigation are left to the TE WG would help
at future meetings?

- Philip Matthews    Nortel Networks     Ottawa, Ontario