Subject: RE: revised charter for MPLS WG

From: Vishal Sharma <[email-masked]>
Date: Wed, 15 Mar 2000 10:38:51 -0500

Vijay,

Thanks for the updated charter, and for including the milestone I suggested.

After looking at it carefully, I have a couple of comments on the revised 
charter.
Specifically, it is unclear why item
4 in the problem statement, item 6 under Objectives, and the last milestone all 
have
the qualifier "optical crossconnects."  A look at the multitude of drafts 
submitted recently
to the WG on this subject reveals that the mechanisms or procedures are not 
confined
to optical crossconnects --- they talk of dealing with sub-lambda channels, 
which requires
electronic intervention to pull the channels out from a wavelength.

In fact, it is not even clear what the term "optical crossconnects," strictly 
speaking, refers to?
An all-optical device, an OEO device, a digital cross-connect with optical 
interfaces?

While the qualifier is certainly appealing, it is unclear to me that it has 
been made sufficiently
precise for it to be part of the formal Charter of the MPLS WG, or that it 
should be used in the
charter at all.

Also, it seems to me that when talking about "control plane intergration" what 
we are really talking
about is the integration of signalling functionality with a number of transport 
elements in the network,
of which "optical crossconnects" are but one. For example, are we excluding 
intelligence on OADMs
for dynamically adding/dropping "optical LSPs"?

It appears that the last paragraph in the charter attempts to provide some 
definition of optical cross connects,
but is not precise enough. The phrase "in this environment specific wavelengths
or lambdas are used instead of labels," is confusing and unclear. What is used 
in this environment
is simply an "optical label" if you will, that includes information on the 
wavelength, fiber, sub-channel, etc.
If indeed "specific wavelengths" are the only ones used in this environment, 
then it would
seem to exclude the case of OEO's (where you go to sub-wavelength channels), 
and, by extension, the
many drafts that talk about them.

All of this notwithstanding, for clarity, I'd like to suggest a rewording of 
Objective 6 as follows:
"Specify extensions to the protocols and procedures that are used for signaling 
explicit routes and
for effecting fast recovery so that they may be used in optical crossconnects."

At this point, I am not sure of what alternative wording to suggest, since I 
need to think about
it and make a suggestion later.
However, I did want to raise the flag, and get people thinking about the issue.

Thanks,

-Vishal

On Tuesday, March 14, 2000 4:33 PM, [email-masked] 
[SMTP:[email-masked]] wrote:
>
> Here is an update of the WG charter.  There weren't many comments on the
> list -- the main comments were:
>
> Item 1. Support for Aggregated QoS
>
>    Andy Malis ([email-masked])
>    >8.  Define the use of Differentiated and Integrated Services in an MPLS
>    >environment.
>
>    I suggest the above objective be changed to "aggregated QoS", as
> discussed
>    in November.
>
> There was not much discussion this subject matter.  George Swallow felt such
> a change would limit the charter, while Grenville Armitage felt the current
> wording limits the charter to two specific QoS models.
>
> I have reworded the objective to read:
>
>    8.  Define the support of Differentiated and Integrated Services,
> including aggregated QoS, in an MPLS environment.
>
> Item 2. Liaison with other standards bodies
>
>    Andy Malis ([email-masked])
>    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..
>
> There was no consensus on this issue.  However, ODSI was added to the list
> of standard bodies already mentioned in the charter.  If a formal liaison
> is required with a particular standards body, the IAB will be contacted
> to set one up.
>
> Item 3. Division of work between TE-WG and MPLS WG
>
>    Philip Matthews <[email-masked]>
>    Should the new charter contain some words about the
>    division of work between the MPLS WG and the TE WG?
>
> There was no further discussion on this subject.  The charter currently
> does not address this subject.
>
> Item 4. LSP Recovery
>
>    Vishal Sharma ([email-masked])
>    I would like to suggest adding the following as a milestone:
>
>    Produce specifications for protocols and procedures that support
>    LSP recovery
>
> A milestone has been added for this.
>
> ----------------------------------------------------------------------------
> ----------
>
> 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 support of Differentiated and Integrated Services,
> including aggregated QoS, 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, ODSI 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).
>
> Aug 00 - Produce specifications for protocols and procedures that support
>          fault recovery in an MPLS environment
>
> Dec 00 - Produce specifications for a MPLS control plane for optical
>          cross-connects (Standards Track).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  << File: ATT00006.html >>

---

From: "Loa Andersson" <[email-masked]>
Date: Wed, 15 Mar 2000 17:24:43 +0100

All,

I've three smaller (I hope :-) comments on the charter.

1. The charter says that the WG should co-ordinate the work with other 
   organizations "such as OIF, ITU-T, ANSI, ODSI etc." I've the feeling
   that the list is a bit random. There could be other organizations 
   that should be on that list, what about MSF? This is minor.
   I'm more concerned about the "coordintion/cooperation", what mandated 
   does it vest on who and on behalf of whom? I've a feeling that there 
   might be legal (US legal :-) aspects here.

2. The milestone 
   "Aug 00 - Produce a document which defines operation with RSVP for
    unicast destinations. (Standards Track)."
   It is the first time RSVP is mentioned in the charter and it is to
say
   the least unclear what the intentions is. At least three different
   tasks could be what is intended:
   - tunneling of RSVP signaling through a LSP
   - making RSVP the only protocol for label distribution in the unicast
case
   - using RSVP for resource reservation on established LSP's

3. The objective 7 says
   "7.  Specify standard procedures of carrying label information over
   various link level technologies including ATM."
   I suggest that it is changed to 
   "7.  Specify standard procedures of carrying label information over
   various link level technologies."

/Loa

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: [email-masked]