Subject: [mpls] Progressing draft-asm-mpls-tp-bfd-cc-cv

From: Loa Andersson <[email-masked]>
Date: Wed, 26 May 2010 20:18:37 +0200

Working Group,

The working group chairs have decided that
draft-asm-mpls-tp-bfd-cc-cv-04 will be adopted as an MPLS working
group draft.

Authors, please resubmit this draft as
draft-ietf-mpls-tp-bfd-cc-cv-00.txt
without any changes but the file name and the date.

George is part of the design team, so I am taking responsibility for
this decision. I have, of course, discussed it carefully with George
who I trust to give me his opinion of what is best for the working
group.

Please note that this draft is limited to a part of the OAM problems
space. Specifically it addresses CC, CV and RDI. The whole of the OAM
problem space in is scope for the MPLS working group. Many parts are
already covered by existing RFCs and working group drafts. Other parts
are still for future development. As is normal for all working group
work, if there are deficiencies in the current draft, please raise the
issues on the mailing list and propose solutions as modifications to
this draft. If new drafts are needed to cover other parts of the OAM
problem space, please start writing them.

We would like to clarify that we working group chairs have full
authority to make this decision under RFC 4677. This states:

   "An Internet Draft can be either a Working Group draft or an
   individual submission. Working Group drafts are usually reviewed by
   the Working Group before being accepted as a WG item, although the
   chairs have the final say."

Our decision was guided by existing documents that describe MPLS-TP.
These documents have been published as RFCs after IETF last call and
have been reviewed and approve for publication by the ITU-T. These
documents have full community consensus across the IETF and ITU-T.

These documents imply that there will be only one OAM solution for
MPLST-TP. The documents further makes clear that this solution will
be produced by the IETF (with ITU-T review) and that it will be
based on existing IETF MPLS mechanisms and within the IETF MPLS 
architecture.

The relevant references are as follows.

1. RFC 5317 Section 2

   The JWT recommended that future work should focus on:

   In the IETF:

   Definition of the MPLS "Transport Profile" (MPLS-TP).

   In the ITU-T:

   Integration of MPLS-TP into the transport network,

   Alignment of the current T-MPLS ITU-T Recommendations with MPLS-TP
   and,

   Termination of the work on current T-MPLS.

   This says that the IETF is responsible for doing the technical work
   developing MPLS-TP, a.k.a "desing authority".

2. RFC 5317 Section 9

   The JWT found no show stoppers and unanimously agreed that they had
   identified a viable solution. They therefore recommend Option 1.
   They stated that in their view, it is technically feasible that the
   existing MPLS architecture can be extended to meet the requirements
   of a Transport profile, and that the architecture allows for a single
   OAM technology for LSPs, PWs, and a deeply nested network. From
   probing various ITU-T Study Groups and IETF Working Groups it appears
   that MPLS reserved label 14 has had wide enough implementation and
   deployment that the solution may have to use a different reserved
   label (e.g., Label 13). The JWT recommended that extensions to Label
   14 should cease.

The JWT recognized that the architecture allows for a single OAM
solution. Implicit in this recognition is a desire for a single
solution.

3. The JWT Report Slide 17
   http://www.ietf.org/MPLS-TP_overview-22.pdf or the pdf version of
   RFC5317.

   Solution Based on existing Pseudo-wire and LSP constructs

The JWT held that solutions should be based on existing IETF MPLS
mechanisms.

4. RFC 5654 Requirement 2

   2 The MPLS-TP design SHOULD as far as reasonably possible reuse
   existing MPLS standards.

This restates the JWT note about being based on existing IETF MPLS
mechanisms.

Loa with help from George
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Di Giglio Andrea <[email-masked]>
Date: Thu, 27 May 2010 15:00:42 +0200

Dear Loa, All,

        I do not argue about the formal correctness of the decision you took.
However, even if the form and was respected, and had probably had every right to make the decision you made, I think a bit hasty switch to adopt of the document as n MPLS working.

In fact,  I believe that  an uncertain outcome of the poll, is to mean, the need for further discussion.

        Best regards

        Andrea

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Loa Andersson
Inviato: mercoledì 26 maggio 2010 20.19
A: [email-masked]; [email-masked]; [email-masked]
Oggetto: [mpls-tp] Progressing draft-asm-mpls-tp-bfd-cc-cv

Working Group,

1. RFC 5317 Section 2

   In the IETF:

   In the ITU-T:

2. RFC 5317 Section 9

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.