Subject: Draft Minutes of MPLS wg

From: George Swallow <[email-masked]>
Date: Fri, 19 Nov 1999 14:16:06 -0500

Attached are the draft minutes from Washington.  Many thanks to Andy
Malis.

...George
======================================================================

Draft Minutes, MPLS meeting, IETF-46, Washington DC
Wednesday and Thursday, November 10-11, 1999, 9:00 - 11:30

Chairs: Vijay Srinivasan, Ericsson, George Swallow, Cisco

Minutes taken by Andrew Malis, Lucent

Agenda:

First Session, Wednesday, November 10, 1999, 0900 - 1130

1.   Agenda Bashing & WG Status

2.   Le Faucheur, DiffServ over MPLS, draft-ietf-mpls-diff-ext-02.txt

3.   Gibson, Management of QoS, draft-gibson-manage-mpls-qos-00.txt

4.   Gray, LDP State, draft-ietf-mpls-ldp-state-02.txt

5.   Jamoussi, CR-LDP update, draft-ietf-mpls-cr-ldp-03.txt

6.   Aboul-Magd, Service Definition, draft-aboulmagd-srvc-def-crldp-
  00.txt

7.   Ashwood-Smith, Improving Topology DB Accuracy, draft-ashw-mpls-te-
  feed-00.txt

8.   Ash, Routing Guidelines for Efficient Routing Methods, draft-ash-
  itu-sg2-routing-guidelines-00.txt

9.   Awduche, Multiprotocol Lambda Switching, draft-awduche-mpls-te-
  optical-00.txt

10.  Basak, Multiprotocol Lambda Switching, draft-basak-mpls-oxc-
  issues-00.txt (not yet posted)

Second Session, Thursday, November 11, 1999, 1300 - 1500

1.   Andersson, Reroute Framework, draft-andersson-reroute-frmwrk-
  00.txt

2.   Owens, Protection/Restoration Requirements, (no draft)

3.   Shew,  Restoration, draft-shew-lsp-restoration-00.txt

4.   Swallow, Bypass Labels, draft-swallow-rsvp-bypass-label-00.txt

5.   Berger, RSVP refresh reduction, Update on what occurred in RSVP WG

6.   Theimer, OAM Functionality, draft-theimer-mpls-oam-requ-00.txt

7.   Andersson, Capabilities Set, draft-loa-mpls-cap-set-01.txt

8.   Carson, NIST Implementation

9.   Leu/Jensen, Interoperability Update

10.  Charter Update

First session, Wednesday, 0900 - 1130

George began the meeting by announcing that we had to change the order
of the agenda because the video projector was not yet working.

1. Mark Gibson, Nortel, Management of QoS, draft-gibson-manage-mpls-
qos-00.txt

Mark discussed managing MPLS using SIP.  The operation of MPLS is left
unchanged, but SIP is used to determine the path based on QoS metrics.
SIP also performs the reservation.

The reference architecture is a session control layer using ISUP, a
core management layer, using SIP, and a core transport layer, using
MPLS.  MEGACO is the interface between the session control layer and
the core transport layer, while COPS is the interface between the core
management layer and the core transport layer.

The MPLS configuration is a network of known-size ER-LSP paths, which
act like trunks.  The trunks are advertised using the SIP REGISTER
method.  SIP then sets up sessions within the trunks.

The key features are dynamic route selection, provides a mechanism for
guaranteed QoS, enables traffic engineering, scalable, small level of
session state, and MPLS operation is unaltered.

This draft was presented for information only at this point.

George Swallow asked a couple of questions:

Q: Does this require carrying labels in SIP?
A: No

Q: How is the binding done?
A: There is syncing up between the endpoints, and then a CR-LDP or
RSVP session setup occurs.

2. Peter Ashwood-Smith, Nortel, Improving Topology DB Accuracy, draft-
ashw-mpls-te-feed-00.txt

Peter spoke on improved topology database accuracy with LSP feedback
via CR-LDP.

The problem being solved is that the distribution of link resource
information via OSPF or ISIS is not timely enough when many LSPs must
be set up or reprovisioned as a result of changes in the network.  The
result is a step function where LSPs establish in bursts with minimum
flood interval-sized pauses.  Reducing the flood intervals does not
help - it just makes the step-size smaller.

Another alternative is to make the route computation non-deterministic
(guess), but this results in non-lowest cost routes in the best case,
or excessive fruitless hunting in the worst case.

The proposed solution is to  overwrite the topology database with
information learned during connection setup attempts, so that the
topology database is updated to reflect the proper residual bandwidth
following either an unsuccessful or successful connection setup.

They found in simulations that without the feedback, the link state
database always showed more bandwidth available than in the real
network until the next update flood arrived.  The feedback more
tightly bounds the available bandwidth in the database to more closely
match the real network.

He proposed an optional TLV to the CR-LDP notification, mapping ,and
withdraw messages to carry the bandwidth for each link on the path.

Q (Vijay Srinivasan): How stable would this be in a real network with
many endpoints running this?  Did you simulate this with more than
just one endpoint creating LSPs?
A: The simulations did have multiple endpoints requesting LSPs.  If
you only had one endpoint, then you wouldn't need these mechanisms.

Q: Have you considered using piggybacked feedback during failures?
A: Yes, this is in the withdraw messages as well.

Q (Joel Halpern): You need to emphasize in the document that if you
get feedback, and then a flood comes in, the information from flooding
must override the feedback.  Also, the feedback on failure is much
more valuable than the feedback on success, since the feedback on
success removes available bandwidth from the topology database.
A: That's exactly what you want to happen, so you don't try to open
LSPs over paths that aren't going to be able to satisfy the request.

Q (Tony Li): How do you deal with race conditions when you have
bandwidth info arriving from different sources in non-deterministic
order?
A: I don't care about it, because I'm interested in time scales of
seconds, not milliseconds.

At this point, the video projector was working and we resumed the
normal agenda order.  George announced that he would go over the
working group status update at the end of the second session.

3. Francois Le Faucheur, Diff Serv over MPLS, draft-ietf-mpls-diff-
ext-02.txt

Francois spoke on MPLS support of DiffServ.  He began by presenting
the complicated history of DiffServ over MPLS proposals, and how the
-01 version of this draft was merged with a number of other existing
drafts.  As a result, the document was completely restructured to
specify  media-independent operations (E-LSPs, L-LSPs, forwarding,
RSVP, LDP, etc.  There are also media-specific sections for PPP, ATM,
FR, and LANs.  The deployment scenarios were moved to an appendix.
They added the concepts of an "ordering constraint" among sets of Per-
Hop Behaviors and sets of Behavior Aggregates.

The draft also now discusses the relationship between labels and
Forwarding Equivalence Classes.  The label represents the combination
of a FEC and a precedence or class of service.

On the email list, several possible approaches for E-L-LSPs, 
"L-LSPs supporting multiple PSCs" were proposed.  The approach 
adopted was that E-L-LSPs are not included in the draft for now, 
but the draft was structured to facilitate their future addition 
if that becomes desirable.

They modified the text to reflect that E-LSPs can actually be used to
perform traffic engineering and fast reroute separately for each
ordering aggregate.

They added error handling, and specified that whenever there is a
doubt about whether the LSP can meet the required DiffServ
requirements, the LSP is not established.

They proposed some RSVP and CR-LSP signaling extensions to improve
DiffServ support.

They added text to clarify the relationship between MPLS and Explicit
Congestion Notification.  Non-ECN-capable LSPs do not need to set any
EXP bits aside for ECN.  For ECN-capable LSPs, one EXP bit is used for
DCN.

Open issues:
-    Interworking scenarios between E-LSPs and L-LSPs
-    Administrative domain boundaries
-    LANs/802.1 class of service mechanisms
-    Tunnels - especially, what happens if tunnels cross administrative 
       boundaries?  This may be solved by the DiffServ over tunnels 
       draft in the DiffServ group.
-    CLP mapping

What next:
-    Feedback from the WG if the current specification is appropriate
-    Are there any other open issues?
-    If the open issues can be closed, can we try a trial WG last call
       before Adelaide to surface any issues so that a real last call
       can be issued immediately after Adelaide.

Q (Juha Heinanen): I don't like the necessity for manual configuration
in the routers to determine the mapping of the EXP bits.
A: This has already been discussed at length.  We had the requirement
to not redefine DiffServ, and we're only trying to set up LSPs to
support that.  He's not comfortable with saying that DiffServ requires
too much configuration so it should be fixed in LSP signaling.

George agreed that trying to wrap this up by Adelaide is a very
good goal.

4. Eric Gray, Lucent, LDP State, draft-ietf-mpls-ldp-state-02.txt

Eric wasn't able to present his overheads due to problems with his
laptop, but he will put them up on a public web site.  He said that
this draft has been around with very few comments.  They would like
to go to last call if possible.  It's intended to be an information
draft of the LDP state machine that can be used for code development
or testing. There were several issues that were closed.  The authors
had a discussion with Fred Baker regarding the open security issues,
especially when the state machine receives spurious events in the
form of LDP messages, and the current security section arose from
that discussion. Other received comments were also addressed.

Eric subsequently sent email to the list announcing that his overheads
can be found at:

http://www.mindspring.com/~ewgray/ldpstate

George said that last call will be issued on the list as soon as
Eric's presentation is publicly available.

5. Bilel Jamoussi, Nortel, CR-LDP update, draft-ietf-mpls-cr-ldp-
03.txt

CR-LDP is now in version 3.  Its purpose is to address the
requirements in RFC 2702.  Bilel gave a very quick overview of the
protocol and its history.  The primary recent updates were to align
with recent changes in the LDP specification.  It is now in IESG last
call for Proposed Standard.  There is free PDU processing code on the
Nortel web site, and a Linux implementation is available from the
University of Wisconsin, there was an Interopnet Labs multivendor
interoperability demo, and the ITU has determined CR-LDP as the
signaling protocol for MPLS operation over public ATM data networks.
Determination is a fairly mature status within the ITU. The final vote
on this is expected at the next ITU SG13 meeting.

6. Osama Aboul-Magd, Nortel, Service Definition, draft-aboulmagd-srvc-
def-crldp-00.txt

Osama spoke on a framework for service definition and interworking
using CR-LDP.   He discussed CR-LDP's QoS capabilities, such as the
signaling of traffic parameters, indicating the required service
frequency, and the assignment of different priorities to different
LSPs.  However, it doesn't explicitly define services.  Rather, it
defines building blocks from which services can be defined.  In this
case, a service is defined as a combination of the rules enforced at
the edge and he packet treatment received at the nodes.
The service definition methodology is specifying the policing rules at
the edge and the packet treatment rules though the network.  He
presented a service model for interworking with other domains, such as
non-MPLS domains or MPLS domains using RSVP signaling.

Q: Are you trying to define services?
A: No, I'm just defining the building blocks.

Q (Tom Worster): Tom suggested some additions to the draft to include
using policy systems to set the edge behaviors.  He will work offline
with Osama on this.

7. Gerald Ash, AT&T, Routing Guidelines for Efficient Routing Methods,
draft-ash-itu-sg2-routing-guidelines-00.txt

His draft proposes mechanisms to improve the efficiency and stability
of network routing for MPLS, especially during periods of congestion.
Under congestion, networks can exhibit instability with drastic loss
of network throughput.  State-dependent routing (SDR) path selection
with LSA flooding can lead to large processing overhead and smaller AS
size.

Event-dependent routing (EDR) path selection can improve routing
performance, especially during congestion.  He proposed using EDR to
address these instabilities and inefficiencies.

He also advocated the use of dynamic bandwidth reservation when
setting up LSPs to protect preferred traffic against loss.  He
discussed various dynamic bandwidth reservation methods.

His proposed next steps are to include these guidelines in the traffic
engineering framework draft coming out of the new Traffic Engineering
working group and write a comprehensive informational draft on TE and
QoS methods for multiservice networks.

8. Daniel Awduche, UUNET, Multiprotocol Lambda Switching, draft-
awduche-mpls-te-optical-00.txt

Daniel proposed the use of MPLS for controlling optical cross-connect
control planes in order to reuse work done for MPLS in the layer 2
control plane.  He discussed the evolving requirements in the Internet
for high performance, survivable, and scalable core networks.

He presented an introduction to optical cross-connects (OXCs).  The
premise of the draft is to adopt MPLS traffic engineering control
plane constructs to OXCs.  He compared several possible control-plane
paradigms, including PNNI, MPLS IP LSR, and proprietary.  He proposed
a new paradigm using MPLS IP LSRs for all OXC control uses.  The
advantage is that the work on MPLS traffic engineering can be reused
in the optical context.

He reviewed the ITU-T G.872 Optical Transport Network architecture.
He discussed the requirements for the control plane operation.  He
discussed the commonalties between OXCs and LSRs.  The basic approach
is to adopt IGP extensions for MPLS traffic engineering and MPLS
signaling at the optical layer.

The next steps are to develop domain specific adaptation functions,
articulate end-to-end architectural implications, develop
interoperable extensions to RSVP, CR-LDP, and IGPs, and determine the
role of the IETF in this work.

Q: In the document, you excluded the possibility for in-band signaling
between OXCs.  These should be included.
A: Agreed.

Q (Eric Gray): The level at which OXCs work make it hard to use "ships
in the night" operation with other control models.  It's going to need
an interworking model that is going to involve other groups' work as
well.
A: Agreed.

Q (Antonio Rodriguez-Moral): The draft needs to include the layer
model in addition to the peer model for OXC control.  Also,
addressing and signaling interworking need to be addressed.
A: Agreed on the first comment.  On the second comment, there are two
problems.  One is doing this for an IP-centric network, and the
second problem is how to control OXCs for more generic use.

Q (Liam Casey): Liam was wondering why the draft stopped at optical
switches.  This really can apply to any circuit-switch connection.
He was wondering if the scope of MPLS is for IP-centric networks, or
for MPLS for all possible uses.
A: The scope should be for IP-related uses, at least for now.

Q: There are advantages to multiple control planes.
A: There are two basic issues - building a network and building a
control plane.  There are cases when an architectural separation makes
sense, but other cases when one control plane is correct.

9. Debashis Basak, Fore/Marconi, Multiprotocol Lambda Switching, draft-
basak-mpls-oxc-issues-00.txt (not yet posted)

Debashis spoke on issues in combining MPLS traffic engineering control
with OXCs.  This is an extension to Daniel's draft.  He presented an
example of LSP setup between OXCs, the issues of conservative
wavelength allocation, the impact on link state routing, and the
impact on MPLS signaling.

He noted that OXCs cannot perform label push and pop operations, so
that start and end of tunnel LSPs have to be on an LSR.  There are new
link attributes that will be useful, such as if a link is adjacent to
an OXC or the number of unused wavelengths on a link.  When doing MPLS
signaling, the label being signaled have to represent a wavelength,
and it needs to be able to specify if an LSP is "multiplexable" or
not.

Some additional issues are that today's routers and switches work with
SONET interfaces.  A signaling message may need to distinguish the
channel to use.  There is concern for legacy optical equipment that
would not include MPLS functionality.  That would be modeled as an
optical cloud.  Wavelength paths may need to use greater bandwidth
than they require, due to the fixed nature of lambda bandwidths.

Q (Eric Gray): Eric pointed out a problem in some of the switching
examples in the overheads.
A: This will be corrected in the draft.

George pointed out that the disposition of these drafts will be
discussed during the charter discussion at the end of the next
session.

Second Session, Thursday, 1300 - 1500

1. Loa Andersson, Nortel, Reroute Framework, draft-andersson-reroute-
frmwrk-00.txt

This was the second time Loa presented this draft - he had already
presented it earlier on the same day in the Traffic Engineering
working group.  This is a proposed framework document for the various
MPLS backup restoration proposals.  It discusses the commonalties
between all of the various proposals and discusses requirements for
this type of work.  It doesn't propose a specific reroute scheme but
can be used as a framework for evaluation.  Requirements could include
restoration time, loss bounds, backup capacity, state overhead, and
packet reordering.  Loa asked for input from service providers, and
suggested that this draft perhaps be combined with the other related
drafts being discussed at the meeting.  The WG also needs to decide if
this work belongs here or in the TE WG.

George Swallow announced that he, Ed Kern (one of the TE WG chairs)
and Brad Cain (one of the co-authors of this draft) discussed this
issue after the draft was presented in the TE-WG.  They agreed that
anything MPLS-specific belongs in MPLS, while the more general
requirements for rerouting could be incorporated in the TE-WG
requirements draft.

2. Vas Makam, Tellabs, Protection/Restoration Requirements, draft-
makam-mpls-protection-00.txt (not yet posted)

This was also presented at the TE WG in the morning.  Vas discussed
protection and restoration of traffic engineered IP networks. Their
motivation is that layer 3 or IP routing may be too slow for a core
network that much support high reliability or availability.  However,
Layer 0 (optical) or Layer 1 (SONET) may be limited to ring topologies
and may not include mesh protection or visibility into higher layer
protocols.

They want to facilitate fast recovery of the working traffic while
avoiding layering violations by defining an interworking function
between the layers.   They presented a set of restoration
requirements, such as providing mechanisms for doing path or segment
restoration, configuring the protection path, enabling restoration of
the original path, detecting impairments, and notification.  They
proposed that the WG produce RSVP and LDP/CR-LDP extensions needed for
protection and a WG draft on protection requirements.

3. Stephen Shew, Nortel, Fast MPLS LSP Restoration, draft-shew-lsp-
restoration-00.txt

Stephen noted that it is often difficult to accurately determine when
an LSP fails, or it may take a long time to determine that there was a
failure, and that there is a scaling issue with layer 2 link failures,
since a single link failure could affect thousands of LSPs using that
link.  He described a mechanism for fast detection of MPLS LSP failure
when a link fails and scales to all LSPs affected by the  failure.
This fast detection enables affected LSPs to be quickly recovered onto
backup LSPs. The mechanism relies on a node and network architecture
that integrates layers 1, 2, and 3 topologies and technology.  He
defines layer 1 "cut-through" forwarding for layer 3 service.  When a
physical link that is carrying multiple L1 cut-through paths fails,
each endpoint of all the paths knows about the failure through usual
physical detection methods.  That information is fed up to the MPLS
layer, which moves the traffic onto backups LSPs that use a different
set of L1 cut-throughs.  He said the architecture is similar to draft-
awduche-mpls-te-optical-00.txt.

4. George Swallow, Cisco, Bypass Labels, draft-swallow-rsvp-bypass-
label-00.txt

George also gave this talk in the TE WG.  George presented proposed
extensions to RSVP to support traffic engineering restoration (fast
reroute). The goal is to reroute around failed nodes and to be able to
quickly switch LSPs to predefined backup tunnels, by using the label
stack.  The backup tunnel does "local repair" around the failure by
appearing as a single hop to the original LSP. To effect the repair of
the backed up LSPs, packets belonging to those LSPs are redirected
onto the bypass tunnel.  An additional label representing the bypass
tunnel is stacked onto the redirected packets.  At the penultimate hop
of the bypass tunnel, the label for the bypass tunnel is popped off
the stack, revealing the labels which represent the LSPs being backed
up.  He presented an optimization when a global label space is used
instead of local labels on each interface which adds a new label sub-
object to the route record object.

George said that it "pretty much works", but he is certainly open to
suggestions for improvements.   His objective is 50 ms for
restoration.  He said they can do 12 ms.

Q: (Ram Krishnan): How many tunnels did you test with when you achieved
   12 ms restoration?
A: This was tested with about 100 tunnels.

Q (Peter Ashwood-Smith): Do we lose the use of the mergability bit
when this is used, since the draft reuses this bit?  Should the draft
use a different bit instead?
A: George would like some guidance on how the bit is currently being
used, and would appreciate suggestions.

Q (Peter A-S): Do the refreshes go over the bypass, or does it not
matter?
A: If you're doing the refresh reduction, then there aren't any
refreshes to worry about.

George would like this to be a WG draft.  He's happy to make the
determination on the list once people have had a chance to read the
draft.

5. Lou Berger, LabN Consulting, RSVP refresh reduction, update on what
occurred in RSVP WG

Lou presented an update on what happened in the RSVP Working Group
regarding the refresh reductions.  draft-ietf-rsvp-refresh-reduct-
01.txt addresses RVSP scaling issues in the wide area.  The RSVP WG
met on Tuesday and hotly discussed some of the technical details.  The
consensus is that some specific changes will be made, there will be an
RSVP WG last call after the update, and the draft will be submitted to
be a Proposed Standard.  There specific changes are:

1. Improve error detection of summary refreshed state
2. Allow the use of MESSAGE_ID SRC Lists on multi-access links
3. Remove sub-set implementation
4. No ACK on Bundle messages
5. Add new co-authors to the draft

Other planned changes:
1. Bundling
2. MESSAGE_ID_ACK
3. Add IPv6 c-types for MESSAGE_ID_LIST class
4. Other minor edits and removing inconsistencies

Lou expects to have the draft out in several weeks.

6. Thomas Theimer, Siemens, OAM Functionality, draft-theimer-mpls-oam-
     requ-00.txt

Thomas presented his draft on proposed OAM functionality for MPLS.  He
defining OAM (Operation, Administration, and Maintenance),  discussed
his motivation for MPLS OAM functionality, and presented possible
requirements for OAM in MPLS networks.  He discussed example of OAM
functions,  including fault management, continuity checks, loopbacks,
performance monitoring, and protection switching.  Such capabilities
may be useful in many applications of MPLS networks, but a detailed
set of requirements is currently not available. He solicited further
discussion and input, in particular from network operators and service
providers.

He concluded by asking: Do we agree that the MPLS OAM issues should be
discussed in this WG?  Should we adopt OAM issues as a work item in
this WG?  Please send comments and input to the list.

7. Loa Andersson, MPLS Capabilities Set, draft-loa-mpls-cap-set-01.txt

Loa presented his revised capability set draft.  The purpose is to
describe what MPLS is capable of, and what is required for particular
applications, so that people will know what is interoperable without
having to implement everything.  The goal was to describe a limited
number of "valid" capability sets.  The current draft defines 10
capability sets, including "implement everything".  The methodology
was to identify a number of MPLS "components", such as basic LDP, RSVP-
TE, etc., and show the valid combinations of these components.  A new
revision of this draft is planned for the next meeting.  This is aimed
at being an informational RFC.

8. Mark Carson, NIST, NIST's MPLS Implementation

Mark presented his group's MPLS implementation.  He started by stating
why MPLS is interesting from a research standpoint and why they felt
they needed an experimental platform.  The implemented it on the "NIST
Switch" platform, which are rack-mounted PCs running freeBSD that they
use for networking experiments.  Their current release uses RSVP for
signaling, and they will be incorporating CR-LDP as well.  Version 0.1
came out for the Oslo IETF, and they are currently testing version
0.2.  They are planning 0.3 for the next IETF meeting.  0.2 has ATM
support and also supports -04 of the RSVP tunnel draft.  Version 0.3
will support CR-LDP.  The code can be found at:

http://www.antd.nist.gov/itg/nistswitch

There is a discussion list at:

[email-masked]

The code is in the public domain, and contributions to the code are
encouraged.

9. Bill Jensen, University of Wisconsin and Jim Leu, Ericsson,
Interoperability Update

Bill and Jim discussed the InteropNet Labs MPLS interoperability
demonstration at the Atlanta Networld+Interop trade show.  In Atlanta,
the InteropNet demonstrated VPNs, VoIP/QoS, High Bandwidth IP, and
MPLS.

They demonstrated interoperability for LDP, CR-LDP, and MPLS.  They
had seven vendors and eleven platforms.  For LDP, Cisco, Nortel,
Ericsson, Ficon, and Harris and Jeffries participated.  For CR-LDP,
they had Nortel, Ericsson, and Ficon.   For RSVP, they had Cisco,
Ericsson, FORE, and Juniper.

They accommodated as many transports as possible: Ethernet, ATM, POS.

They ran LDP and CR-LDP together, and RSVP off on its own island.
They tested implementations for conformance to changes in the
specifications.  The LDP testing was very successful.  CR-LDP didn't
complete all of the tests possible due to lack of time and resources,
but those tests that they did do worked well.  Some LDP/CR-LDP
"encounters" included RFC 1700 address family misinterpretation,
obsolescence of TLV x0601 (dropped in draft -04), handling of unknown
TLVs and messages, and inconsistent interpretation of when to use the
Message ID TLV in the Label Mapping Message.

For RSVP, they tested sending Path Messages and reception of RESV
message with TE TLVs (very successful) manually configured explicit
paths (somewhat less successful).

They unintentionally ended up doing some testing of the traffic
engineering enhancements to IS-IS, but they didn't get it to work
completely.

RVSP "encounters": Outside requirements to trigger origination of LSPs
varied between vendors, they found differences in the address used in
explicit path messages, path reservation style support varied between
implementations, and use of PHP on non-PHP capable transports was a
problem (e.g., ATM and lambdas).

They found that MPLS is moving rapidly and they're looking forward to
doing this again at the May Interop.

Their talk can be found at:

http://www.mpls.interop.net/confstuff/ietf46/interoperabilityupdate/index.htm

10. Charter Update

George discussed the current status of the WG.  Much of the charter is
either done or largely complete.

To date, there is one RFC: RFC 2702, Requirements for Traffic
Engineering Over MPLS.

The state of the other working group documents are:

On RFC Editor's queue:

  Multiprotocol Label Switching Architecture
  MPLS Label Stack Encoding

In the hands of the IESG:

  MPLS using ATM VC Switching
  Use of Label Switching on Frame Relay Networks Specification
  VCID Notification over ATM link for LDP
  GIT UUS

In IESG last call:

  LDP Specification
  LDP Applicability
  Extensions to RSVP for LSP Tunnels
  Applicability Statement for Extensions to RSVP for LSP-Tunnels
  Constraint-Based LSP Setup using LDP
  Applicability Statement for CR-LDP
  A Framework for MPLS

WG last call (To, In, Through):

  LDP State Machine
  ICMP Extensions for MultiProtocol Label Switching
  MPLS Loop Prevention Mechanism

Active drafts:

  MPLS Support of Differentiated Services
  Definitions of Managed Objects for LDP
  MPLS Traffic Engineering Management Information Base
  MPLS Label Switch Router Management Information Base

Others:

  Framework for IP Multicast in MPLS
  Carrying Label Information in BGP-4
  RSVP

George presented a score card based on the current charter's work
items.  The items without a * are complete or mostly so; the two items
with a * were not done.

1. Support unicast destination-based routing

2. Support multicast routing *

3. Support hierarchy of routing knowledge

4. Support explicit paths

5. Operate over various link level technologies

6. Specify a standard way to use the ATM user plane: allow operation/co-
existence with standard ATM, specify a 'label swapping' control plane,
take advantage of possible mods to ATM (e.g. VC merge)

7. Discuss support for QoS (e.g. RSVP)

8. Allow direct host (e.g. server) participation *

A summary of the recent ongoing work is:

Active drafts:
  Diff Serv
  MIBs

Less active work:
  Multicast
  RSVP
  BGP

Inactive work:
  Hosts

Recent topics of interest:
  LSP recovery
  OAM functions
  Routing and signaling improvements for TE
  Optical cross-connect

After presenting the above, George then opened the microphone for
discussion.  

Comment: Multicasting hasn't been discussed for a while.  If active
work doesn't continue, it should be removed from the charter.

Vijay said that both of the existing drafts were from vendors.  He
would like to see input from service providers on multicast as well.
George said that there are a number of issues that need to be resolved
in this area, especially for traffic engineering, and volunteers are
needed to do this work.

There was support for adding LSP recovery, optical cross-connects, and
OAM to the charter.  Bilel Jamoussi proposed that signaling
improvements for traffic engineering belong in this WG, but routing
improvements should be done in the routing WGs.

Rob Coltun (Routing Area Director) made the point that the optical
cross-connect work needs to cooperate with the proper other bodies in
this area, such as OIF, ITU-T, ANSI, etc.  George noted that the best
way to liaison to other groups is by having people from those groups
participate in this work, and vice-versa.

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 Davie 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.

George and Vijay will draft a new charter based on the
discussion and put it out on the list for comments.

End of minutes