[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-mpls-tp-process

Network Working Group                                       L. Andersson
Internet-Draft                                              Ericsson Inc
Intended status: Standards Track                                 D. Ward
Expires: January 1, 2010                                   Cisco Systems
                                                                M. Betts
                                                                 Huaweil
                                                           June 30, 2009


 Joint IETF and ITU-T Multi-Protocol  Label Switching (MPLS) Transport
                            Profile process
                 draft-andersson-mpls-tp-process-03.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 1, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Andersson, et al.        Expires January 1, 2010                [Page 1]


Internet-Draft          MPLS-TP document process               June 2009


Abstract

   The decision to develop a Multiprotocol Label Switching (MPLS)
   Transport Profile in cooperation between IETF and ITU-T does not
   fully define and document processes for development of the required
   RFCs.

   This document complements the processes documented in the JWT
   decision with a few separate elements; it:

   o  provides an adaptation of the IETF working group process,

   o  identifies the expected participation in the process by the ITU-T,

   o  clarifies the decision rules regarding MPLS-TP documents.

   This document is not intended to specify any ITU-T process; to the
   extent necessary ITU-T activities will be done according to ITU-T
   process/rules.

   Nor is this document is intended to specify the IETF working group
   process, it is limited to the temporary adaptations of that process
   that is the result of that IETF and ITU-T accepted the proposal in
   the JWT report to jointly develop the MPLS Transport Profile.  In
   general it may be said that these adaptations are introduced to
   ensure a good and consistent document review across the two
   organizations.
























Andersson, et al.        Expires January 1, 2010                [Page 2]


Internet-Draft          MPLS-TP document process               June 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  IETF terms and abbreviations . . . . . . . . . . . . .  5
       1.1.2.  ITU-T terms and abbreviations  . . . . . . . . . . . .  5
   2.  Adaptation of the IETF working group process . . . . . . . . .  7
     2.1.  Adaptation of the IETF working group process . . . . . . .  7
     2.2.  The IETF MPLS-TP process . . . . . . . . . . . . . . . . .  8
       2.2.1.  Developing a MPLS-TP document  . . . . . . . . . . . .  9
   3.  Expectations on ITU-T participation in the process . . . . . . 14
     3.1.  Becoming a MEAD team document  . . . . . . . . . . . . . . 14
     3.2.  Comments on MEAD team documents by participants in the
           ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.3.  Poll for working group documents . . . . . . . . . . . . . 14
     3.4.  Responding to an IETF Working Group Last Call  . . . . . . 15
   4.  Specific guidelines that apply to work on MPLS-TP in the
       ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 17
   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21


























Andersson, et al.        Expires January 1, 2010                [Page 3]


Internet-Draft          MPLS-TP document process               June 2009


1.  Introduction

   When IETF and ITU-T entered into the agreement to develop MPLS-TP,
   the JWT agreement included the decision that the MPLS-TP documents
   should be developed "according to IETF processes".  It was also
   assumed that there would be close cooperation in reviewing these IETF
   documents.  The JWT decision is documented in RFC 5317 [RFC5317].

   However, the process for this close cooperative review was mostly
   left to be decided as the documents evolved.  The ITU-T committed to
   responding promptly to IETF working group last calls, this may
   require the development of the response via correspondence.

   Nor is this document is intended to specify the IETF working group
   process, it is limited to the temporary adaptations of that process
   that is the result of that IETF and ITU-T accepted the proposal in
   the JWT report to jointly develop the MPLS Transport Profile.  In
   general it may be said that these adaptations are introduced to
   ensure a good and consistent document review across the two
   organizations.

   This document complements the process as documented in the JWT
   decision with a few separate elements; it:

   o  Provides an adaptation of the IETF working group process, with
      respect to the role of the teams (MPLS Interoperability Design
      Team (MEAD Team), the Joint Working Team (JWT) and the ITU-T
      MPLS-TP ad hoc team) that has been set up to facilitate the
      development of MPLS-TP; see Section 2.

   o  Identifies the expected participation by the ITU-T in the document
      development process; see Section 3.

   o  Clarifies decision rules regarding MPLS-TP documents; see
      Section 4.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.1.  Terminology

   This section includes a number of terms and abbreviations that are
   used in this document.  The section is split into two subsection;
   IETF terms and ITU-T terms.






Andersson, et al.        Expires January 1, 2010                [Page 4]


Internet-Draft          MPLS-TP document process               June 2009


1.1.1.  IETF terms and abbreviations

   o  JWT - Joint Working Team, a team with participants with experience
      from standards development in the IETF and the ITU-T.

      Note: The JWT is not part of either the IETF or ITU-T, but a group
      that has been set up to facilitate cooperation on MPLS-TP between
      the two organizations.

   o  JWT documents - the set of documents envisioned in the
      documentation of the JWT decision, see RFC 5317 [RFC5317].

   o  MEAD team - MPLS Interoperability Design Team, a temporary team
      with participants with experience from standards development for
      MPLS and transport networks.  The MEAD team is chartered to
      coordinate the development of MPLS-TP within the IETF and to
      coordinate the on MPLS-TP cooperation with the ITU-T.

   o  MPLS-TP documents - the following sets of documents are counted as
      MPLS-TP documents:

      *  Internet Drafts that are coordinated by the MEAD team.

      *  Individual Internet Drafts that addresses the MPLS-TP problem
         space.

      *  Working group Internet Drafts that addresses the MPLS-TP
         problem space.

      *  Internet Drafts that are considered for publication by the IESG
         and that addresses the MPLS-TP problem space.

      *  Internet Drafts that are approved for publication by the IESG
         and that addresses the MPLS-TP problem space.

      *  Published RFCs that addresses the MPLS-TP problem space.

      *  ITU-T Recommendations and draft Recommendations in various
         stages of development that addresses the MPLS-TP problem space.

   Documents that originates from the IRTF RFC stream is NOT considered
   as MPLS-TP documents.

1.1.2.  ITU-T terms and abbreviations

   o  Ad Hoc on MPLS-TP - A team established by SG 15 of ITU-T to
      coordinate the work on MPLS-TP within the ITU-T and to act as a
      focal point for communication with the IETF.



Andersson, et al.        Expires January 1, 2010                [Page 5]


Internet-Draft          MPLS-TP document process               June 2009


   o  Contribution - a contribution is a document that is submitted to
      the ITU-T to advance work on the development of a Recommendation
      or to propose the development of a new Recommendation.

   o  Recommendation - a Recommendation is the ITU-T standards document.














































Andersson, et al.        Expires January 1, 2010                [Page 6]


Internet-Draft          MPLS-TP document process               June 2009


2.  Adaptation of the IETF working group process

   The IETF working group processes as defined in RFC 2026 [RFC2026] are
   for the purpose of the MPLS-TP updated as follows.

   The IETF works according to a 'rough consensus' model, where working
   group chairs determine the consensus after discussions on the mailing
   lists.  This is applicable to the MPLS-TP work also.  The
   mpls-tp@ietf.org is the mailing list used to find out consensus and
   consensus is determined by the MEAD team chair.  After a document has
   become a working group document the consensus is decided by the WG
   chairs and the MEAD team chair jointly.

   A most important part of this process is the information exchange
   between the IETF and ITU-T.  This information exchange consists of
   two equally important pieces:

   o  informal information exchange

      this is done primarily by E-Mail to the relevant mailing lists.
      Information sent from IETF, IETF areas and working groups, or from
      the IETF MEAD team are sent to and areas and the
      ahmpls-tp@lists.itu.int mailing list.  Information sent from ITU-T
      to the IETF should e sent to the MEAD team (mead@ietf.org) and/or
      the mpls-tp@ietf.org mailing list.

   o  formal information exchange

      In addition to E-Mail, a formal information exchange is
      accomplished by liaison correspondence between the two
      organisations.  Exchange of liaisons makes it possible to follow
      the request/response exchange between the organisations in more
      detail.

2.1.  Adaptation of the IETF working group process

   The flow chart below describes the adaption of the working group
   process













Andersson, et al.        Expires January 1, 2010                [Page 7]


Internet-Draft          MPLS-TP document process               June 2009


          .............                   .............
          : Ind Docs  :------+            : JWT docs  :
          .............      |            .............
                |            |                  |
                | ind-00 (1) |  ind-00 (2)      | ind-00 (3)
                |            |                  |
                v            |                  v
        +-----------+        |        +----------------+  (4)  +-------+
        |  WG proc  |        +------->| MEAD team proc |<----->| ITU-T |
        |           |-------+      +--|                |       +-------+
        +-----------+       |      |  +----------------+        (5) |
    +-> ind-00, ind-01, etc |      |   ind-00, ind-01, etc <-+<-----+
    |          | (6)        +--+---+       (6) |             |
    +----------+               |(7)            +-------------+
      review                   +----+               review
                                    |
                             poll for wg doc -----------------+
                                    |                         | (7a)
                                    v                         v
                             +-------------+       (8)    +-------+
                +----------> |   wg doc    |<------------>| ITU-T |
                |            +-------------+              +-------+
                |              | +-> wg-00, wg-01, etc        |
                |              | |          | (9)             | (10)
                |              | +----------+<----------------+
                |         (11) |    review
                |              v
                |     +-----------------+     (12)    +---------+
          (14b) |     |  wg last call   |<----------->|  ITU-T  |
                |     +-----------------+             +---------+
                |        |     ^      |
                |    (13)|     |(14a) | (15)
                |        v     |      |
                |       +---------+   |
                +-------|  ITU-T  |   |
                        +---------+   |
                                      |
                                      v
                            +-----------------+
                            |  req for publ   |
                            +-----------------+


2.2.  The IETF MPLS-TP process

   This section gives guidelines for how the flow chart above could be
   traversed.




Andersson, et al.        Expires January 1, 2010                [Page 8]


Internet-Draft          MPLS-TP document process               June 2009


2.2.1.  Developing a MPLS-TP document

   Individual MPLS-TP documents may take different paths through the
   this process, the numbers in the list below are mapped to the numbers
   in the flow chart above.

   Although the different paths through the flow chart are given as
   'options' it is always possible for the MEAD team to step in and take
   over the shepherding of a particular MPLS-TP Internet Draft .  This
   is done in cooperation between the MEAD team chair, the relevant
   working group chairs and the document editors/authors.

   1.   They may be intended for and managed by a working group.

        This means that the author, or authors, of such a document have
        chosen to send the document to a working group instead of
        running through the MEAD team.  Normal IETF process will kick in
        in such cases and working group chairs will agree to which
        working group(s) such a document will be taken.

   2.   They may be coordinated by the MEAD team.

        This means that the author, or authors, of such a document have
        chosen to send the document to the MEAD team to be coordinated
        with the rest of the MPLS-TP documents that is in the purview of
        the MEAD team.

   3.   They may be originated by the MEAD team based on the JWT
        decision.

        In documentation of the work of the JWT, there is a proposed
        document structure.  The MEAD team used this structure to decide
        on a set of documents that will, when completed, constitute the
        MPLS-TP standard.  This set of documents may change slightly, if
        - e.g. - it becomes more appropriate to split a single document
        into two or more, or if some new aspect of MPLS-TP needs to be
        specified.

   4.   Everytime a document is accepted by the MEAD team into the set
        of documents coordinated by the MEAD team a liaison is sent to
        the ITU-T with a pointer to that document.  At the same time a
        note is sent to the MPLS-TP ad hoc team mailing list informing
        the list that the document has become a MEAD team document.

        The ITU-T may chose to respond to the liaison but is not
        required to do so, see Section 3 and Section 4.





Andersson, et al.        Expires January 1, 2010                [Page 9]


Internet-Draft          MPLS-TP document process               June 2009


   5.   At any time, it is possible for the ITU-T SG and Question
        participants to send review comments on MEAD team documents.  It
        is also possible for the MEAD team to ask for such reviews and
        comments.

        Any time such input or requests are sent between the two
        organizations it SHALL be accompanied by a note from the MPLS-TP
        ad hoc team chair(s) to the MEAD team mailing list, or from the
        MEAD team chair to the MPLS-TP ad hoc team mailing list.  This
        is done to enhance the efficiency of the information exchange.

   6.   A working group or the MEAD team may issue requests for general
        comments on MPLS-TP documents at any time, if it is deemed
        appropriate to extend these requests to the MPLS-TP ad hoc team
        this is done via a note according to entry (5) in this list.

   7.   If a MPLS-TP document seems mature enough to become a working
        group document, a poll is done on the mpls-tp mailing list and
        the appropriate working group mailing list (7), this request
        will also be sent to the ITU-T as a liaison (7a) and a note will
        also be sent to the MPLS-TP ad hoc team.

        Which working group a document goes into is decided jointly
        between the MEAD team, working group chairs of the potential
        working groups and the document editors/authors.

        If the document is accepted as a working group document the
        working group takes over the revision control of the document.

        The ITU-T is expected to respond to the liaison within in the
        time indicated in the liaison, see Section 3 and Section 4.

   8.   Every time a MPLS-TP document is accepted as a working group
        document by any IETF working group, a liaison is sent to the
        ITU-T with a pointer to the document.  At the same time, a note
        is sent to the MPLS-TP ad hoc team mailing list informing the
        list that the document has become a working group document.

   9.   Working group documents may be reviewed in several steps, every
        time such a review is initiated the MPLS-TP ad hoc team is
        notified (10).

        Note that most comments leading to updates of working group
        documents are a result of spontaneous individual reviews and
        comments from the individual participants in the MPLS-TP effort.

   10.  Every time a review is initiated by a working group the
        appropriate ITU-T SGs and Questions will be notified by E-Mail



Andersson, et al.        Expires January 1, 2010               [Page 10]


Internet-Draft          MPLS-TP document process               June 2009


        to the MPLS-TP ad hoc team.

        Optionally the request for review may be accompanied by a
        liaison to formalize the request.

        The MPLS-TP ad hoc team is responsible for ensuring that any
        e-mail requests are copied/forwarded to the relevant SGs and
        Questions.

   11.  When a document is deemed mature enough, a working group last
        call is initiated.  At this time the action describe under item
        12 in this list MUST be executed.

   12.  Procedures to be followed when a working group last call is
        initiated.

        *  A liaison containing a request for participation in the
           working group last call will be sent to the appropriate ITU-T
           SGs and Questions.

        *  A notification that the working group last call is taking
           place will be provided to the MPLS-TP ad hoc team via E-Mail
           sent to the MPLS-TP mailing list.

        *  ITU-T is REQUIRED to respond to the liaison within the time
           indicated.  The MPLS-TP ad hoc team is expected to verify
           that all the SGs and Questions within the ITU-T that need to
           respond to the working group last call are aware that it has
           been issued.

   13.  When all last call comments are addressed and/or responded to,
        the document will be sent to the ITU-T, asking if the document
        is ready to be sent to the IESG with a request for publication.
        The response sought from ITU-T is either an acknowledgment that
        the document is ready to publish or a response that there is
        further work that needs to be done.

        Note: WG last call may be re-iterated, for the entire document
        or limited to only verify the updates made because of an earlier
        working group last call.

   14.  The ITU-T has one week to respond (yes or no) to the question
        posed in (13).

        The answer can be either "yes - go ahead" (14a), in which case
        the Working Group will request publication; or ...

        ... it can be "no - more work is needed" (14b), in which case it



Andersson, et al.        Expires January 1, 2010               [Page 11]


Internet-Draft          MPLS-TP document process               June 2009


        will go back into the normal working group process to identify
        what is needed.

   15.  When the ITU-T gives the final acknowledgement (14a), a request
        for publication will be sent to the IESG (15).

        The document that is sent to the ITU-T in step (13) and which
        generates a positivie response from ITU-T (14a) is sent
        unchanged, save for editorial changes, to the IESG with a
        request for publication (15) as a RFC.

        Once this request for publication is sent, the last point in
        this process where it is acceptable to allow ITU-T influence in
        the development of a document is passed.  After this point, the
        document will be handled as any other IETF document.

2.2.1.1.  Naming conventions for MPLS-TP Internet Drafts

   To make it easier to search in the IETF Internet Draft repositories
   the the following guidelines should be followed for the MPLS-TP
   Internet Draft filenames.

   o  All MPLS-TP Internet Draft should include the sequence "mpls-tp"
      in the filename.

   o  Individual MPLS-TP Internet Draft should be named according to
      this format:

      draft-name-mpls-tp-topic-??.txt

      "name" is the last name of the main editor, or an acronym
      indicating the last names of the set of editors.

      "topic" indicates the content of the draft, e.g. "oam-framework".

      "??" indictes a two digit version number, starting with "00".

   o  MPLS working group documents should be named according to this
      format:

      draft-ietf-mpls-tp-topic-??.txt

   o  MPLS-TP documents from other working groups shouldbe named
      according to this format:

      draft-ietf-wg-name-mpls-tp-topic-??.txt

      "wg-name" is the acronym for any working group chartered to do



Andersson, et al.        Expires January 1, 2010               [Page 12]


Internet-Draft          MPLS-TP document process               June 2009


      MPLS-TP work, e.g. pwe3 or ccamp.


















































Andersson, et al.        Expires January 1, 2010               [Page 13]


Internet-Draft          MPLS-TP document process               June 2009


3.  Expectations on ITU-T participation in the process

   The IETF and ITU-T processes for the development of the MPLS-TP
   standards interconnect at the following point in the flow chart
   above: (4), (5), (7a), (8), (10) and (12).  This section briefly
   describes what is expected to happen on the ITU-T side at the
   interaction points.

3.1.  Becoming a MEAD team document

   (4) is a point at which the MEAD team communicates to the ITU-T that
   a document is considered to be accepted for coordination by the MEAD
   team.

   The ITU-T is expected to respond to the communication with a simple
   ACK or NAK, however a non-response is counted as an ACK.

   An ACK means that ITU-T accepts that the document has become a MEAD
   team document, a NAK means that ITU-T has issues that needs to be
   resolved before the document is allowed to progress.

3.2.  Comments on MEAD team documents by participants in the ITU-T

   (5) and (10) offer possibilities for ITU-T, or people active in the
   ITU-T, to send un-triggered comments on MEAD team or working group
   documents.  Such comments shall be sent to the mpls-tp list and for
   working group documents also to the appropriate working group mailing
   list.  Comments received in this way will be treated in the same way
   any as other individual comments received on the IETF documents.

3.3.  Poll for working group documents

   (7a) is the point at which an IETF working group informs the ITU-T
   that a poll to progress a document to an IETF working group document
   has been started.

   It is not necessary, or required, for the ITU-T to respond to this
   message.  If the ITU-T has serious concerns these should be provided
   via a liaison statement.  If the ITU-T has no serious concerns it is
   allowed and encouraged that individual participants provide comments.
   Such responses shall be sent to the appropriate working group and
   mpls-tp mailing lists and represent the view of the person sending
   the mail.

   An Internet Draft is ready to become a working group draft if it
   meets at least the three criteria below.





Andersson, et al.        Expires January 1, 2010               [Page 14]


Internet-Draft          MPLS-TP document process               June 2009


   o  it is within the charter of the working group

   o  it addresses a problem that needs to be solved

   o  it is a good enough start toward solving this problem

   Responses to polls checking if a document is ready to become a
   working group document should be limited to considering if the
   document meets those three criteria.

3.4.  Responding to an IETF Working Group Last Call

   (12) is the point in the process where ITU-T is made aware of that an
   IETF working group last call has been started.  The working group
   last call is issued when a working group document is getting close to
   being ready for publication.  The intention is to make sure that
   there are no important pieces missing and that technical details are
   correct.

   According to the JWT decision ITU-T is required to respond to a
   working group last call within the time set in announcing the working
   group last call.

   The chair of an IETF working group that starts a working group last
   call will send a liaison to the ITU-T announcing the working group
   last call.  A message will also be sent to the MPLS-TP ad hoc team.
   The IETF will make a best effort attempt to target the SGs and
   Questions that should be involved in responding to the working group
   last call.  However, the ITU-T has to make sure that the appropriate
   entities within the ITU-T participate in responding to the working
   group last call.  The ITU-T MPLS-TP ad hoc team coordinates the
   development of the ITU-T response to the working group last call.



















Andersson, et al.        Expires January 1, 2010               [Page 15]


Internet-Draft          MPLS-TP document process               June 2009


4.  Specific guidelines that apply to work on MPLS-TP in the ITU-T

   These guidelines apply to progressing work on MPLS-TP in the ITU-T.

      Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T
      Study Group or Question.

      Before the ITU-T initiates any new work (i.e. items not previously
      identified by the JWT) based on such contributions the ITU-T shall
      send a liaison to the IETF.  The message will go to the MEAD team,
      and the team is responsible for creating a consolidated IETF
      response.

      The IETF is expected to respond to the information that a new
      MPLS-TP work item has been proposed with an ACK or NAK.

      If the response is a NAK that work item is held until the issues
      is resolved.

































Andersson, et al.        Expires January 1, 2010               [Page 16]


Internet-Draft          MPLS-TP document process               June 2009


5.  IANA considerations

   There are no requests for IANA allocation of code points in this
   document.















































Andersson, et al.        Expires January 1, 2010               [Page 17]


Internet-Draft          MPLS-TP document process               June 2009


6.  Security considerations

   This document defines a process adaptation for the cooperation
   between IETF and ITU-T and thus does not introduce any new security
   considerations.














































Andersson, et al.        Expires January 1, 2010               [Page 18]


Internet-Draft          MPLS-TP document process               June 2009


7.  Acknowledgments

   Thanks to Eric Gray who helped with grammar and useful comments.
   Thanks to Tom Petch who spent time trying to sort out what I wanted
   to say and has sent comments that helped clarify the document.














































Andersson, et al.        Expires January 1, 2010               [Page 19]


Internet-Draft          MPLS-TP document process               June 2009


8.  References

8.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5317]  Bryant, S. and L. Andersson, "Joint Working Team (JWT)
              Report on MPLS Architectural Considerations for a
              Transport Profile", RFC 5317, February 2009.

8.2.  Informative references

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.
































Andersson, et al.        Expires January 1, 2010               [Page 20]


Internet-Draft          MPLS-TP document process               June 2009


Authors' Addresses

   Loa Andersson
   Ericsson Inc

   Email: loa.andersson@ericsson.com


   David Ward
   Cisco Systems

   Email: dward@cisco.com


   Malcolm Betts
   Huaweil

   Email: malcolm.betts@huawei.com

































Andersson, et al.        Expires January 1, 2010               [Page 21]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/