Subject: Draft MPLS minutes

From: George Swallow <[email-masked]>
Date: Fri, 28 Mar 2003 18:09:21 -0500

MPLS Working Group

WG Chairs: George Swallow <[email-masked]>, Loa Andersson 
<[email-masked]>

George chaired the meeting.  Andy Malis took the minutes.
(Thanks Andy!)

1.  Overview of ISOCORE Interoperability Tests

Rajiv Papneja, [email-masked]

Rajiv presented the results of the March MPLS interoperability testing
at ISOCORE.  They tested RSVP-TE with FRR, MPLS LDP signaling, and
MPLS as a transport for L2 VPNs, specifically including VPLS.

Their service provider sponsors provide the list of functionality to
be tested as input to the test plans.  They had ten vendors
participating in the testing, and they built a network with both core
LSRs and edge LERs.  They used ISIS-TE as the IGP for RSVP-TE.

More than 30 interoperability issues were discovered in 7 days of
testing.  More than 15 fast reroute scenarios were tested, and they
achieved <40 ms switch-over in the scenarios.

The found a number of issues in the testing.  Some of the highlights
of these issues were:

* They found issues with reverse compatibility in FRR for the nodes
   that don't support it.  There was an issue with ISIS-TE in that not
   all vendors had implemented the latest drafts, so they recommend
   that all vendors update their code.

* They also suggest that all vendors support ERO in the RSVP-TE Path
   message (they found that some did not).

* In the LDP HELLO message, they found incompatible values in the
   transport address TLV, and an ambiguity in the definition of the LDP
   TLV length definition.  They recommended on how these problems need
   to be corrected in RFC 3036.

* There were also ambiguities in the value of the LSR-ID over targeted
   and basic discovery.  This also needs to be fixed in RFC 3036.

* Some vendors were advertising per-interface label space for targeted
   LDP sessions when they should have been using per-platform labels
   due to an ambiguity in the Martini signaling draft.

* Backward compatibility issues between the different revisions of the
   VPLS draft.

* An ambiguity in the Address List TLV in Address Withdraw messages.

Their upcoming testing will be GMPLS interoperability in April, MPLS
Leading Edge testing in July and August, and the 4th MPLS 2003 Demo
following the MPLS 2003 conference.

2.  TE-related drafts

Reoptimization of explicit loosely routed MPLS TE paths
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-loose-path-reopt-01.txt
Jean-Philippe Vasseur, [email-masked]

This draft proposes a mechanism for the reoptimization of loosely
routed explicit paths. A loosely routed explicit path is as a path
specified as a combination of strict and loose hop(s) that contains at
least one loose hop and zero or more strict hop(s). The path
calculation (ERO expansion) to reach a loose hop is made on the
previous hop defined in the TE LSP path. This draft proposes a
mechanism that allows:

- the TE LSP head-end LSR to trigger a reoptimization on every loose
   hops along the path,

- an LSR to signal to the TE LSP head-end that a better path exists to
   reach a loose than the path in use. A better path is defined as a
   path with a lower cost, where the cost is defined by the metric used
   to compute the path.

This primarily applies to inter-area TE LSPs and inter-AS TE LSPs when
the path is defined as a list of loose hops (generally the loose hops
are the area border routers) but the mechanism is also applicable to
any loosely routed explicit paths within a single routing domain.

If and only if at least a better path exists in an area or AS,
reoptimization is triggered.

The reoptimization can be event-driven or timer-driven, and triggered
from both the head-end and from a mid-point LSR.

Comments have been received from service providers acknowledging their
interest in deploying this technology.

Rahul Aggarwal suggested an improvement in one of the mechanisms in
the draft to simply the operation in some situations.  JP agreed with
the suggestion.

Philip Matthews asked a question about the use of PathErr
notification, since they can be lost in the network.  JP explained how
the draft can compensate for such losses.

JP proposed that this become a working group draft. George said that
the IETF has to decide how it's going to treat the entire set of
inter-area and inter-AS TE drafts before this draft can be accepted.
This topic is going to be discussed later in the week at the sub-IP
Directorate meeting.  Plus, decisions to accept drafts are always made
on the email list.  There may also be working group charter changes
required before taking this on.  A hum 'vote' showed some support for
making this a WG draft in the room.

Definition of an RRO node-id subobject
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-nodeid-subobject-00.txt
Jean-Philippe Vasseur, [email-masked]

In the context of MPLS TE fast reroute, the merge point (MP) address
is required at the point of local repair in order to select a backup
tunnel intersecting a protected TE LSP on a downstream LSR.  However,
existing protocol mechanisms are not sufficient to find the MP address
in multi-area or multi-domain routing networks. As a result, the
current MPLS Fast Reroute mechanism cannot be used to protect
inter-area or inter-AS TE LSPs from a failure of an area border router
or Autonomous System border router. This document specifies the use of
existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to
define the node-id subobject in order to resolve this issue.

Use of MPLS TE FRR bypass has been identified as a key requirement by
service providers.  This draft proposes a simple flag definition to
allow backup tunnel selection of inter-area/inter-AS TE LSPs.

Again, JP asked this draft be adopted as a WG draft.  George said that
this is a very simple point solution, and very straightforward, and
he's in favor of adopting it.  There was widespread support in the
room.  This will be ratified on the list.

MPLS Traffic Engineering Fast reroute: bypass tunnel path computation for
   bandwidth protection
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-02.txt 

Jean-Louis Le Roux, [email-masked]

This draft proposes a model called the "Facility based computation
model" for computing bypass tunnels paths in the context of the MPLS
TE fast reroute, while allowing bandwidth sharing between bypass
tunnels protecting independent resources. Both a centralized and a
distributed path computation scenarios are covered. The required
signaling extensions are also discussed in the draft.

Jean-Louis described how the model can efficiently perform the path
computation.

He showed how the draft fits into section 6 of the current MPLS WG
charter, and presented the history of the drafts that were combined in
order to produce this draft and the changes from -01 to -02.  The
major change was the introduction of the SDLG concept - Shared SRLG
(shared risk link group) Dependency Link Groups.

Conclusion: FRR is now largely implemented and deployed.  BW
protection is a key requirement to protect sensitive traffic on
non-over-provisioned networks.  The facility-based computation model
seems the most efficient approach for bypass tunnel placement.

Vishal Sharma said that he had suggested some improvements to the
draft that removes the need for protocol extensions.  Jean-Louis said
that those comments applied to version 1 of the draft, and not to
version 2.

Jean-Louis asked that this be made a WG draft.  Most of the room had
not yet read it, so George was hesitant to make a determination now.
He said it should be discussed further on the list.

MPLS Traffic Engineering Soft preemption
http://www.ietf.org/internet-drafts/draft-meyer-mpls-soft-preemption-00.txt
Matthew Meyer, [email-masked]

This draft discusses MPLS TE soft preemption, a set of protocol
modifications extending the current concept of preemption with the
goal of reducing or eliminating traffic disruption of preempted TE
LSPs.  Under present RSVP-TE signaling methods, LSPs are immediately
displaced upon preemption.  The introduction of a new preemption
pending flag helps to more gracefully mitigate the re-route process of
displaced LSPs.  For the brief period soft preemption is activated,
reservations (though not necessarily traffic levels) are in effect
overbooked until the LSP can be re-routed.

The problem to be solved is that preemption can be unnecessarily
disruptive to the network, especially in conjunction with Diffserv,
and preemption may occur even when there is excess capacity in the
network.  There is a concrete and operational issue that needs to be
resolved.  This draft proposes RSVP-TE mechanisms that can be used to
treat the lower-priority flows better.

George, as one of the authors of RFC 3209, said that there is a hole
in that RFC and this RFC plugs it, and he supports this as a working
group item.

Rahul said that he's also supportive of this, and he proposed an
improvement to the policing function. Matthew agreed.

Kireeti Kompella said that we need to discuss RRO vs. PathErr on the
list.  JP said that the first drat used PathErr, but it was changed to
RRO in the second draft based on implementation experience.

Adrian Farrel asked that the authors not come up with protocol
solutions to respond to nonstandard deployed versions of the
specification.  Matthew and George both agreed.  The room agreed that
this be made a WG draft, and it will be ratified on the list.

3.  Graceful Restart

LDP DoD Graceful Restart
http://www.ietf.org/internet-drafts/draft-thomas-mpls-ldp-dod-restart-00.txt
Bob Thomas, [email-masked]

LDP graceful restart is a mechanism that helps reduce the negative
effects on MPLS traffic caused by the restart of an LSR's control
plane, specifically by the restart of its LDP component on LSRs that
are capable of preserving MPLS forwarding state across the
restart. RFC 3478 defines procedures for LDP graceful restart for
downstream unsolicited label distribution but leaves procedures for
downstream on demand label distribution a subject for future study.
This document defines graceful restart procedures for downstream on
demand label distribution.

Bob gave an overview of how his draft builds upon the mechanisms
already in RFC 3478, and specifies changes to the Label Request and
Label Abort messages.  It also makes changes to the behavior of a
neighbor router immediately following an LDP outage.

Bob asked that the WG accept the completion of LDP restart as a work
item, and this draft as the way to address the issue.

Rahul said that he was one of the authors on RFC 3478, and at the time
that document was done, there was no requirement for DoD.  He asked
what the requirement is for this draft.  Bob said that the motivation
is MPLS over ATM, which uses DoD.  There are MPLS over ATM deployments
that could take advantage of this.  Rahul also had some technical
suggestions that he will take offline with Bob.

There was widespread support for making this a WG document.  It will
be ratified on the list.

4.  OAM

OAM Requirements for MPLS Networks
http://www.ietf.org/internet-drafts/draft-nadeau-ietf-oam-requirements-01.txt
Tom Nadeau, [email-masked]

As transport of diverse traffic types such as voice, frame relay, and
ATM over MPLS become more common, the ability to detect, handle and
diagnose control and data plane defects becomes critical. Detection
and specification of how to handle the defects is important, because
such defects may not only affect the fundamental operation of an MPLS
network, but also because they may impact SLA commitments for end
customers of that network.

This draft describes requirements for user and data plane MPLS
operations and management. These requirements have been gathered from
network operators who have extensive experience deploying MPLS
networks, and some of these requirements have appeared in other
documents, including Y.1710.  This draft specifies OAM requirements
for MPLS, as well as for applications of MPLS such as pseudowire voice
and VPN services.

At the last meeting, the authors were directed to combine their
separate drafts into a single OAM requirements draft.  This draft is
the result of that process.  Tom would like to see it accepted as a WG
document.

Dave Allen, the co-author, said that other Standards Develop
Organizations are using this document as a stake in the group for IETF
MPLS OAM requirements.  The group showed support.

Y.1711 and LSP-PING
http://www.ietf.org/internet-drafts/draft-allan-y1711-and-lsp-ping-00.txt
Dave Allen, [email-masked]

Y.1711 and LSP-PING are products of ITU-T SG13/Q3 and the IETF MPLS WG
respectively. Each is reflective of the design philosophies of the
communities of their origin.

The purpose of this draft is to compare and contrast design elements
of the two approaches. The conclusion drawn is that the approaches are
complementary and comprehensive instrumentation of MPLS is ultimately
possible using both.

Dave gave an overview of Y.1711.  In Nov. 2002 it was recommended for
publication.  It focuses on point-to-point LSPs, without penultimate
hop pop (PHP).

There has been ongoing new work in order to support
multipoint-to-point LDP networks using PHP.  It uses a "bloom filter"
to encode the FEC information as a 128-bit string.  The initial focus
is mis-branching detection, and current proposals relate to LDP
availability.

He compared Y.1711 to LSP-PING, which is based on the ping/traceroute
paradigm.  It has good diagnostic capabilities, but is difficult to
scale for proactive detection.

Dave's conclusion is that the two protocols are complementary in
philosophy and design.  Y.1711 has utility as a detection tool, and
then you use LSP-PING and traceroute from a CLI to find out what's
going wrong.

Dave concluded his talk by inviting people to read his Y.1711 FEC-CV
tutorial, available at
http://standards.nortelnetworks.com/y.1711_fec_cv_public.ppt

Kireeti said that this is a good comparison of the two approaches, and
the fact they are not competing, but are complementary.  He would like
to help with some of the wording for the LSP-PING part.  He also had
some comments on the definition of "transaction" in the draft - he
would like to see that improved.  He also pointed out that LSP-PING
can be run periodically to use it as a detection mechanism.  The CLI
part is mostly for traceroute, rather than ping.  He compared LSP-PING
to the Frame Relay local management interface, which polls for status
every 10 seconds.  The difference between Y.1711 and running LSP-PING
periodically is that you are notified of outages in seconds rather
than milliseconds, but you are still notified.

Tom Nadeau said that he things the scalability concerns with LSP-PING
are unnecessarily harsh in the document, and that the document is
tilted more towards Y.1711 than it should be.

Shahram Davari said LSP-PING has become more complicated as the work
on it has progressed, and that it now really isn't that much simpler
than Y.1711.

Detecting MPLS Data Plane Liveness
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-02.txt
Kireeti Kompella, [email-masked]

This document describes LSP-PING, which can be used to detect data
plane failures in MPLS Label Switched Paths.  There are two parts to
the draft: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation; and
mechanisms for reliably sending the echo reply.

Kireeti discussed the recent changes in the draft.  Many
clarifications were added, ECMP support was added, and the router
alert option is a MUST in echo requests.

There are still issues to be fixed, so there will be at least one more
revision.  The current text on the MPLS TTL is broken, and it will be
fixed.  Sections 5 and 11 will be removed.  The label stack in
downstream mapping with clarified.  Downstream mappings still need
clarification.  ECMP address selection needs to be expanded upon.  The
timestamp will be changed to NTP format.

Next steps: New revision in the next couple of weeks, and reissue the
WG last call.

Rahul said that there is a lot of value in LSP-PING in L3 VPNs.
Kireeti said that just IP ping works fine for this application.  Rahul
talked about why LSP-PING is valuable in this situation.  George said
that a good place to discuss this issue is in the framework document
(which doesn't exist) or in the requirements document.  George is
going to propose in the sub-IP meeting that such a document be
developed in this WG.

Marco Carugi proposed that existing technologies should be examined to
see how it can be used in PPVPN troubleshooting.  George agreed.
Kireeti said that Tom Nadeau is working on how to use LSP-PING
primitives with other protocols than MPLS, such as L2TPv3.  There was
general agreement that we need a document that discusses the total set
of tools that can be used in this context.

5.  MIBs

Multiprotocol Label Switching (MPLS) Traffic Engineering Management
   Information Base for Fast Reroute
http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-01.txt
Tom Nadeau

This draft defines a MIB module with managed objects for MPLS fast
rerouting.

Tom reported that the current status is that we've gained a lot of
experience and the MIB has been updated based on that, and is almost
ready for working group last call.  The major changes were adding full
support for both Facility and One-to-One backup.  The conformance
statement was updated to require either, but there is a common section
that is mandatory.  There are two implementations, and a third one is
on the way.  Tom is pretty confident that the MIB works and after the
next revision will be ready for working group last call.  Please send
comments to the mailing list.

Multiprotocol Label Switching (MPLS) Label-Controlled ATM and
   Frame-Relay Management Interface Definition
http://www.ietf.org/internet-drafts/draft-nadeau-mpls-lc-if-mib-00.txt
Tom Nadeau

This MIB module completes the picture for the base MPLS MIBs by
managing label-controlled Frame Relay and ATM MPLS interfaces (this
function was left out of the base MIBs).

It's been updated based upon MIB review and comments on the list.
Implementations have started, and feedback is coming in on that as
well.  He said that this should be progressed as a separate document
from the base MIBs, and be accepted as a WG document.

Very few people in the room have read the draft.  George asked for
more people to read it and comment.

Multiprotocol Label Switching (MPLS) Management Overview
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt

Tom also gave an update on the Management Overview document.  The
authors agree that the document is ready to progress because it
reflects all pending updates to the MPLS MIBs, including the TE MIB.
There will be a quick re-spin and Tom would like it go to last call at
that time.

George said that a last call will be issued shortly after the meeting.

6.  Explicitly routed Multicast

Requirements for Point-to-Multipoint capability extension
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt 

Seisho Yasukawa, [email-masked]

This document presents a set of requirements for adding
Point-to-Multipoint (P2MP) traffic engineering to MPLS. It identifies
the functional and performance extensions required to realize
MPLS-based Content Distribution Networks. It also identifies
functional extensions required to implement CDN/VoIP/VPN service
convergence networks. These extensions can be used to provide high
performance and scalable broadband service network with MPLS.

Yasukawa-san discussed the requirements in terms of market trends in
the explosive growth of broadband subscribers, especially in Japan.
Service providers much create a new broadband service infrastructure
to meet this demand.  It must accommodate not only IP, but current
voice traffic as well.  Among applications for these services include
VoIP, VPNs, and content distribution, including IPTV, live
distribution, video conferencing, and VPN multicast.

There are a number of technical challenges to this sort of a service
network.  A primary challenge is that current MPLS mechanisms are not
optimized for multipoint distribution due to its point-to-point
nature.

The requirements in the draft include the coexistence of P2P and P2MP
LSP tunnels, P2MP path computation in the IGPs, P2MP LSP management
based on tree-based RRO, QoS control mechanism (SE/FF) for P2MP LSPs,
IPv4 and IPv6 support, interworking with IP multicast, and VPN
multicast support.

A number of possible broadband applications for this technology are
discussed in the draft.

Conclusion: P2MP MPLS is attractive technology for next generation
broadband IP service convergence network.  He proposed defining a P2MP
MPLS signaling protocol extension based on conventional RSVP-TE.

George said that this general topic is in the WG's overall charter,
but there needs to be a revision to the charter before this can become
a working group draft since there's no specific work task for this at
this time.

Philip Matthew remarked that there should be cross-pollination with
the MBONE-TE folks, since that is where many of these requirements are
being discussed.

Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-01.txt
Alan Kullberg, [email-masked]

Point-to-multipoint technology will become increasingly important with
the dissemination of new, real-time applications, such as content
delivery services and video conferences, which require P2MP real-time
transmission capability with much more bandwidth and stricter QoS than
non-real-time applications.

This draft defines protocol extensions to RSVP-TE in order to
establish, maintain, and teardown a P2MP LSP. These extensions allow
service providers to offer services that utilize P2P and P2MP LSPs in
the same service network.

Alan talked about the changes in the draft from the first revision.
The point is to extend RFCs 2205, which supports multicast but not TE,
and 3209, which supports TE but not multicast, to support both
multicast and TE.

Alan asked for more feedback on the WG list, and he would like to make
it a WG draft.  Scott Bradner (SubIP Area Director) said that the IESG
needs to approve a charter change in order to add this as a new work
item for the WG.  It's premature to ask the WG to make this a WG
draft.

7.  Header Compression

George said by way of introduction that this set of drafts cannot be
accepted as MPLS working group items yet until after the Sub-IP
Directorate meeting later in the week, because these don't very
clearly sit in any particular working group or area at this time.
This work was first presented in the Adelaide meeting three years ago,
and its status has been very much unclear since then.

Requirements for End-to-End VoIP Header Compression
http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt
Jerry Ash, [email-masked]

VoIP typically uses the encapsulation voice/RTP/UDP/IP.  When MPLS
labels are added, this becomes voice/RTP/UDP/IP/MPLS.  For an MPLS
VPN, the packet header is at least 48 bytes, while the voice payload
is typically no more than 30 bytes. VoIP header compression can
significantly reduce the VoIP overhead through various compression
mechanisms.  This is important on access links where bandwidth is
scarce, and can be important on backbone facilities, especially where
costs are high (e.g., some global cross-sections).  This draft gives a
problem statement and requirements for end-to-end VoIP header
compression, possibly over MPLS.

Jerry gave an overview of the list of requirements from the draft,
from providing efficient voice transport to robustness to packet loss
and delay minimization.  He discussed the background of the work
over the last three years, and then described the two proposed
solution drafts, using cRTP (RFC 2508) and end-to-end header
compression.

End-to-End VoIP Header Compression Using cRTP
http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-01.txt

This draft proposes to re-use the methods in cRTP to determine the
header compression context and to use the cRTP session context ID to
route a compressed packet between the ingress and egress routers.

End-to-End VoIP over MPLS Header Compression
http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-01.txt

This draft proposes to use RSVP extensions to signal the header
compression context and other control messages between the ingress and
egress LSR.  It provides two approaches to determining the header
compression context: a) re-use the methods in cRTP to determine the
context, and b) re-use the methods in George Swallow's and Lou
Berger's "simple" approach to determine the context.

Scott is nervous about application-dependent solutions, and wanted
clarification on what "end-to-end" meant.  This means from voice
gateway to voice gateway, rather than true end station to end station.

The main issue is finding the right home for this work - some people
believe that the MPLS WG is the right place, and the authors would
like to propose that this is the right place.

Scott wanted to make sure that the authors were aware of the robust
header compression work ongoing in the transport area.  The answer is
yes.  In fact, the primary author of that work (Steve Casner) also
thinks this work belongs in the MPLS WG.

George and Scott agreed that this will be brought up in the Sub-IP
Directorate meeting.

8.  Draft Status Update

George Swallow

New RFCs
RFC 3443, TTL Processing in MPLS Networks (PS)
RFC 3469, Framework for MPLS-based Recovery (INF)
RFC 3477, Signaling Unnumbered Links in RSVP-TE (PS)
RFC 3478, Graceful Restart Mechanism for LDP (PS)
RFC 3479, Fault Tolerance for LDP and CR-LDP (PS)
RFC 3480, Signaling Unnumbered Links in CR-LDP (PS)

RFCs (On RFC Editor's Queue)
LSP Hierarchy with Generalized MPLS TE (PS)
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-08.txt

George said this has been on the editor's queue for a long time.
Scott said that it's waiting for normative references.

Link Bundling in MPLS Traffic Engineering
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-04.txt

Including these two, there are now a total of 27 MPLS RFCs, so the WG
has been prolific.

IESG Last Call
MPLS LDP Query Message Description
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-06.txt
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 

IESG Evaluation
Improving Topology Data Base Accuracy with LSP Feedback
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-05.txt

This is on the IESG agenda for the next teleconference, in two weeks.

Awaiting action on BGP Restart
Graceful Restart Mechanism for BGP with MPLS
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-02.txt
Note: Last call in IDR working group - ends 11/29

Yakov Rekhter said that this is implemented by several vendors and
interoperable.  It is on hold in IDR until BGP is published.

Awaiting updates from Authors
MTU Signaling Extensions for LDP
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-00.txt

George asked Kireeti for the status.  Kireeti said that further
clarifications are needed, but he's been unable to contact his
coauthor.  He promised an update in the next month.  The last call
will need to be redone.

Multiprotocol Label Switching (MPLS) Traffic Engineering Management 
Information Base
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-09.txt
Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management 
Information Base
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-05.txt

Bert Wijnen said that if we don't have the final versions of these
documents by the next IETF, they will all be put in the waste bin.
Tom is planning to send updated revisions soon.

Nearing completion
Detecting Data Plane Liveliness in MPLS
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-02.txt

Other Drafts
Encapsulating MPLS in IP or GRE
http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-00.txt

This is ready for working group last call.  A last call will be issued
after the meeting.

Applicability Statement for Restart Mechanisms for LDP
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-applic-00.txt

Adrian said that he's waiting on what happens with the DoD restart
document, because it should be included in this document.  George
might rather get this out there first, since it will be an
informational RFC. There will be a WG last call after the meeting.

9. Charter Discussion

There will be a spin on the WG charter between now and the next
meeting.  If there are additions that people would like to be added to
the work plan, please put them on the list.

George is currently leaning towards adding an OAM framework document,
multi-area/multi-AS TE, soft preemption, and the point-to-multipoint
TE extensions.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 31 Mar 2003 11:21:20 -0800

>on it has progressed, and that it now really isn't that much simpler

It seems that I have been misquoted. A more accurate quote is:

"Shahram Davari said LSP-PING has become more complicated as the work
on it has progressed, and that it now neither simple nor efficient. This
fact has been recognized by the authors, and in fact an earlier text that
suggested LSP-PING is a simple and efficient protocol has been taken out of
the draft"

Thanks,
-Shahram