Subject: [mpls-tp] New I-D desccribing how the IETF will review MPLS-TP Recommendations

From: Adrian Farrel <[email-masked]>
Date: Fri, 15 Jan 2010 14:27:53 +0000

Hi,

Stewart and I have written an I-D describing our expectations of how the 
IETF expects to review and contribute to ITU-T Recommendations on MPLS-TP.

Although this might be expected to have come from the ITU-T, they say that 
they are unable to do more than document existing process (which is already 
documented in process Recommendations) because anything else would be "a 
change in process" and would require consent at a very high level. So we are 
left with the somewhat suboptimal situation where we document our 
"expectations".

Please note that there are a number of Recommendations and RFCs that 
describe the "cooperative process" for work shared by the ITU-T and IETF. 
This draft covers a different situation where the ITU-T is producing 
documents to describe aspects of MPLS-TP, but the design authority for 
MPLS-TP remains within the IETF. In this situation, the ITU-T is responsible 
for generating the text in the Recommendations, and the IETF needs to 
provide a review and agree that the text is OK for publication.

We would welcome your comments on ways to clarify and improve the text, and 
your questions about areas that are unclear.

We have provided the text to the ITU-T's management across MPLS-TP and have 
had some useful comments back from Malcolm Betts (co-chair of the ITU-T's Ad 
Hoc Team for MPLS-TP). We also used a liaison from Study Group 15 as the 
basis for some of the description of process.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 15, 2010 2:00 PM
Subject: I-D Action:draft-farrel-mpls-tp-recommendation-review-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
> Title           : IETF Expectations of Participation in Development and 
> Review of ITU-T Recommendations on MPLS-TP
> Author(s)       : A. Farrel, S. Bryant
> Filename        : draft-farrel-mpls-tp-recommendation-review-00.txt
> Pages           : 12
> Date            : 2010-01-15
>
> The decision to develop a Multiprotocol Label Switching (MPLS)
> Transport Profile (MPLS-TP) in cooperation between the IETF and the
> ITU-T is documented in RFC 5317 as the report of the Joint Working
> Team on MPLS-TP. As part of this development process, the
> International Telecommunications Union - Telecommunications
> Standardisation Sector (ITU-T) will develop a number of
> Recommendations that document the integration of MPLS-TP into the
> transport network. Those Recomendations will not define any aspects
> of MPLS-TP protocols or procedure because that work is reserved for
> the IETF as the design authority for MPLS-TP.
>
> This document sets out the IETF's expectations of how the IETF,
> through individual participation and through consensus decisions,
> will contribute to in the development, review, and approval of those
> Recommendations.
>
> This document does not modify any existing ITU-T or IETF procedures,
> but shows how those procedures can be used to facilitate cooperation
> for the MPLS-TP project.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-tp-recommendation-review-00.txt

---

From: <[email-masked]>
Date: Fri, 15 Jan 2010 18:04:28 +0000

Adrian,

My 2p.

1) Section 1.2 is titled "Purpose and Intent of Cooperation on MPLS-TP" but
the text seems to more along the lines of "this is how ITU-T should work
with IETF for items under IETF design authority". The text is valuable but
the title is misleading IMO.

2) For a document that is about how IETF expects to work with (provide input
to) ITU-T the only ITU Recommendation referenced is A.8. Are there other
useful Recommendations that should be referenced?

3) I think there should be more text/detail on what the IETF expects with
respect to providing input during AAP Last Call. Section 2.2 states that
during AAP last call "members of the ITU-T can submit comments". For
example, can the IETF make comments via a liaison during AAP last call? If
an Invited Expert has been invited to provide input during the production of
the draft Recommendation are they allowed to make comments during AAP last
call?

Ben

On 15/01/2010 14:27, "Adrian Farrel" <[email-masked]> wrote:

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 17 Jan 2010 12:03:29 +0200

Adrian,
My understanding of the outcome of the  JWT work has been that:
1. MPLS-TP will be developed by the IETF in accordance with ITU-T requirements
2. These requirements as well as specific MPLS-TP solutions will be eventually documented as RFCs
3. IETF will liaison I-Ds dealing with MPLS-TP to ITU-T and process their input at all the phases of its process
4. As a consequence, ITU-T will not develop any Recommendations pertaining to MPLS-TP.

Looks like this is not what is going to happen, in particular, ITU-T will develop Recommendations dealing with MPLS-TP.
Could you please explain how did this happen?

My personal experience of processing the same set of original concepts in multiple SDOs proves that this results in
a very messy situation with lots of minor discrepancies between the approved documents and confusion.
(I refer to the process of standardization of TDM PWs which resulted in 4 slightly different documents, approved accordingly
by IETF (RFC 4553, 5086 and 5087), ITU-T (Y.1413 and Y.1453), MEF (MEF-8) and BBF (MFA 4.1and MFA 8.0.0.
Tracing the differences between those (mainly the IETF and ITU-T versions can be traced on the PWE3 mailing list even now.)

Do we really need to do all that again, only on a much larger scale? (And yes, I know that it is good for job security:-)

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, January 15, 2010 4:28 PM
> To: [email-masked]
> Subject: [mpls-tp] New I-D desccribing how the IETF will 
> review MPLS-TP Recommendations
> 
> Hi,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 17 Jan 2010 13:35:49 -0000

Hi Sasha,

I think you are wrong on your fourth point.

RFC 5317 says (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.

The first two of these ITU-T bullets require work on ITU-T Recommendations.
And later in Section 2 we also have:

   It proposed that the ITU-T should:

      Develop ITU-T Recommendations to allow MPLS-TP to be integrated
      with current transport equipment and networks, including in
      agreement with the IETF, the definition of any ITU-T-specific
      functionality within the MPLS-TP architecture via the MPLS change
      process [RFC4929],

      Revise existing ITU-T Recommendations to align with MPLS-TP,

      ITU-T Recommendations will make normative references to the
      appropriate RFCs.

So I think it is clear that the ITU-T will develop Recommendations on 
MPLS-TP.

BUT, as it says in the Abstract of 
draft-farrel-mpls-tp-recommendation-review-00.txt

   Those Recommendations will not define any aspects
   of MPLS-TP protocols or procedure because that work is reserved for
   the IETF as the design authority for MPLS-TP.

So you are right on your general point. There is NO INTENTION to develop any 
part of the technical solution for MPLS-TP outside the IETF. However, there 
is intention to document MPLS-TP within the ITU-T to:
- deprecate the T-MPLS Recommendations
- express MPLS-TP within the ITU-T architecture
- cover aspects of MPLS-TP that would normally be out of IETF scope (such as 
equipment specifications)

To reiterate: in all those cases, the Recommendations will:
- reference RFCs not write/rewrite normative technical text
- not define any new protocols or procedures for MPLS-TP
- be subject to review and agreement by the IETF

Hope this helps,
Adrian

> Looks like this is not what is going to happen, in particular, ITU-T will 
> develop Recommendations dealing with MPLS-TP.
> My personal experience of processing the same set of original concepts in 
> multiple SDOs proves that this results in
> (I refer to the process of standardization of TDM PWs which resulted in 4 
> slightly different documents, approved accordingly
> Tracing the differences between those (mainly the IETF and ITU-T versions 
> can be traced on the PWE3 mailing list even now.)
>
> Do we really need to do all that again, only on a much larger scale? (And 
> yes, I know that it is good for job security:-)
>
> Regards,
>     Sasha
>
>
>

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 18 Jan 2010 16:53:53 +0000

Hi Ben,

> My 2p.

Thanks.
At the current exchange rate, that is worth exactly 2p.

> the title is misleading IMO.

You're right.
The title in this doc and in [MPLS-TP-PROCESS] (from where it was copied) is 
misleading.
Will try to dream up something. Possibly...

Purpose, Intent, and Procedures for Cooperation on MPLS-TP

> useful Recommendations that should be referenced?

There may be.
I was kind of hoping the ITU-T management would fill us in on this. We don't 
need a full detailed breakdown, but some high-level pointers might be good.

> the draft Recommendation are they allowed to make comments during AAP last

I think the technical answer is that the IETF, through liaison, acting as 
part of ISOC (a sector member) can make comments during AAP last call.

However, I think this would be pretty bad form!
By the time we reach AAP last call, the IETF will have already reviewed 
*and* agreed the text of the Recommendation. So, unless there are comments 
from other people that will result in technical changes (in my understanding 
this is not acceptable during AAP last call) there would be no reason for 
the IETF to make comments during AAP last call.

Now, I'm not an expert on this stuff, so it would be good if someone with 
greater understanding could chime in. Perhaps, however, we should document 
this stuff to show what we believe is the case.

Thanks,
Adrian

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 17:19:31 +0000

Adrian,

> this stuff to show what we believe is the case.

I think it would be good to write it down as the draft is to document IETF
expectations, they may not get met (e.g. Because ITU process doesn't allow
it) but writing them down will flush out those issues and let us see the
dependencies (e.g. Understanding that the meeting the document goes for
consent may be the last opportunity for technical comments).

Ben

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 18 Jan 2010 17:27:57 +0000

> consent may be the last opportunity for technical comments).

How about...

5. IETF Input to the ITU-T Last Call and Approval Process

   This document does not modify the ITU-T's last call and approval
   process as defined in Recommendation A.8 [A.8].

   The IETF's expectation is that, by the time last call is held, the
   IETF will have already reviewed and agreed the text of the
   Recommendation. Thus, it is not expected that the IETF will need to
   make any comments during last call. If, however, an issue is
   discovered during the last call period, it will be sent to the ITU-T
   in a formal liaison.

   If substantive comments are submitted to the ITU-T from other sources
   during the last call period they will be addressed by modifying the
   draft Recommendation. When all parties are satisfied, an additional
   review will be initiated within the ITU-T and it is the IETF's
   expectation that the IETF would be notified of any changes and given
   the opportunity to comment and agree the changes. If, after the
   additional review there are still objections, the Recommendation will
   be returned to the next meeting of the study group for further work.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 20:51:44 +0000

Works for me. Ben