Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

From: Greg Mirsky <[email-masked]>
Date: Mon, 2 Feb 2009 10:21:22 -0500

Ross,
my understanding is that the work on T-MPLS, including review of any new
contributions, to be discontinued at ITU-T. Thus IETF might expect that no
new contributions on T-MPLS would be accepted in SG or Question meetings. I
think that the liaison is trying to express that and encourage ITU-T to
finalize MPLS-TP requirements as soon as possible. If my understanding is
correct, then I'd use your version but make the sentence a bit shorter:
-    We also see that there is a need to coordinate between our two
     organizations so that T-MPLS related contributions to the ITU-T
     are not accepted into SG or Question meetings.

Regards,
Greg

On Wed, Jan 28, 2009 at 10:51 AM, Ross Callon <[email-masked]> wrote:

> This is an awkward sentence:
>
>  -     We also see that there is a need to coordinate between our two
>      organizations so that contributions to the ITU-T is not accepted
>      into SG or Question meetings on T-MPLS in such a way that it is
>      practice is impossible for IETF to comment on them.
>
> How about (slight improvement, still not perfect):
>
>  -     We also see that there is a need to coordinate between our two
>      organizations so that T-MPLS related contributions to the ITU-T
>      are not accepted into SG or Question meetings in such a way that
>      it is not practical for the IETF to comment on them.
>
> Ross
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Loa Andersson
> Sent: 28 January 2009 05:51
> To: [email-masked]
> Subject: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP
>
> All,
>
> this is the third liaison that we will send to ITU-T shortly.
>
> We have two incoming liaisons on the cooperation, both are
> "For Information@ and we strictly don't need to respond. They
> were sent to the MEAD team and to the IETF/IAB respectively.
>
> There are however such progress in the cooperation, that I
> think it is appropriate to respond that we noted and encourage
> the steps they've taken. There are also a few things that we
> need to sort out when it comes to exchange of information
> between the two organizations.
>
> Comments are welcome, I intend to send this liaison early the
> week of Feb 9.
>
> /Loa
> --
>
>
> Loa Andersson
>
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  +46 8 632 77 14
>
>                                       email:
> [email-masked]
>                                               [email-masked]
>                                               [email-masked]
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 5 Feb 2009 13:38:56 +0100

Loa, 

In attachment my proposed changes to this LS in order to keep the text
aligned with what has been discussed and agreed in December

Italo 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Wednesday, January 28, 2009 11:51 AM
> To: [email-masked]

---

From: Ross Callon <[email-masked]>
Date: Thu, 5 Feb 2009 12:16:10 -0500

I would strongly object to removing the text regarding deprecating
T-MPLS. We saw in multiple past discussions (most notably at the ITU
meeting in Seoul a year ago) that there are numerous incompatibilities
between the old T-MPLS work that went on in ITU (prior to the Seoul
meeting) and existing and widely deployed IETF MPLS and GMPLS standards.
If T-MPLS were to be deployed, based on the long list of
incompatibilities that have been found, we could reasonably expect
serious network meltdown to be a likely outcome (although precise
details are nearly impossible to predict when there are incompatible
standards, so we can't be confident of any particular result). Thus
deprecating the old T-MPLS work is extremely important. 

Is there actually useful work on transition from the old T-MPLS work to
the current MPLS-TP work? I don't see how you can transition away from
something that is likely to melt down your network. 

I don't like the change to "must be approved", since approval of
documents in the IETF depends upon whether the documents are technical
sound. Of course we will try to approve things in a timely fashion, but
whether this happens will depend upon the quality of the submitted
documents. Loa's original text "need to have approved" makes the point
of the importance of getting these approved on time, but does not sound
like it is telling the IESG that they are required to approve the
document. 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BUSI ITALO
Sent: 05 February 2009 07:39
To: Loa Andersson; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-TP

Loa, 

Italo

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Feb 2009 17:33:18 -0000

It was my understanding that the whole purpose of all of the work was to 
deprecate T-MPLS.
This includes work in the ITU where T-MPLS Recommendations will be replaced 
by MPLS-TP recommendations over time. The process of replacement is exactly 
deprecation.

And people need to understand this. They are free to implement and deploy 
anything they want in their equipment/networks. No-one constrains them in 
any way. They may use existing T-MPLS Recommendations as the basis of their 
work. But they have to understand that the rest of the world is moving on 
and that the ITU and IETF's new MPLS-TP work will deprecate the ITU's T-MPLS 
work.

Adrian
----- Original Message ----- 
From: "Ross Callon" <[email-masked]>
To: "BUSI ITALO" <[email-masked]>; "Loa Andersson" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 05, 2009 5:16 PM
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Feb 2009 17:57:26 +0000

Italo

I object to removing the text stating that T-MPLS is a deprecated
technology.

The plan of record in the two organizations is to
deprecate T-MPLS and start again on an IETF-MPLS
platform.
 
Please lets not have a repeat of the debate that took
place the first week in Geneva - we have too much
technical work to do.

Stewart

<https://ciscosupport.webex.com/ciscosupport/j.php?ED=107380702&UID=1028667352&PW=15c5610f0702100f>

BUSI ITALO wrote:
>> ------------------------------------------------------------------------
>>

---

From: Thomas Walsh <[email-masked]>
Date: Thu, 5 Feb 2009 13:31:03 -0500

I think this discussion is showing it is now time to confront the issue
once and for all regarding deprecation of the existing T-MPLS
Recommendations.  

Note it is perfectly acceptable for IETF to respond in this new liaison
to the ITU-T on whether the handling of the status of T-MPLS in force
Recommendations has been satisfactory.   

Note that in the previous IETF liaison to the December 2008 SG 15
meeting withdrawal of T-MPLS Recommendations was identified as a
desirable solution.  

ITU-T SG 15 indicated their process did not allow for immediate
deprecation, hence there was a compromise reached at the December
meeting of SG 15 which put a warning notice on each of the existing
T-MPLS Recommendations concerning their status.

The previous IETF liaison also notified ITU-T that "T-MPLS is not an
MPLS-based architecture" and that the use of "T-MPLS will cause
confusion in the industry".

Events since the December 2008 ITU-T meeting would seem to bear out this
statement from the IETF and use of T-MPLS is still causing confusion.  

I object to the changes that Italo is proposing as we are not talking
about a transition from T-MPLS to MPLS-TP.  Transition was never agreed
to in IETF, the JWT or the ITU-T.  I believe the exact agreement was
T-MPLS was to be terminated; not transitioned.  I will supply more
detailed comments on Italo's suggested edits in a separate email.

I believe IETF should use this liaison to respond to ITU-T on whether
the current ITU-T solution in response to the December 2008 IETF liaison
asking for withdrawal of T-MPLS Recommendations has been satisfactory.  

Since ITU-T process did not allow immediate deprecation, and because the
end result is continuing confusion, I would suggest the IETF response
this time should indicate that IETF requires ITU-T to "quickly initiate
a process that will lead to deprecating all existing T-MPLS
Recommendations" (my suggested words in quotes).

Important: I do not believe having MPLS-TP supersede T-MPLS
Recommendations is acceptable as a solution. Recommendations that are
superseded remain on the ITU-T web site as earlier implementations.
Since IETF has very clearly stated T-MPLS is not MPLS Technology, and
T-MPLS Recommendations continue unauthorized use of the MPLS Ethertype
and Label 14, maintaining them as superseded Recommendations in the
future is unacceptable.   

Therefore, the ITU-T deprecation process is the only possible solution
and must be initiated by next SG 15 meeting and completed as soon as
possible.

Tom

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Adrian Farrel
> Sent: Thursday, February 05, 2009 9:33 AM
> To: Ross Callon; BUSI ITALO; Loa Andersson; [email-masked]
MPLS-
> TP
> and that the ITU and IETF's new MPLS-TP work will deprecate the ITU's
T-
> MPLS
MPLS-
> TP

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 5 Feb 2009 14:22:34 -0500

Italo,

After reading your proposed changes to the third liaison statement and
the subsequent emails, I went back to re-read the incoming liaisons
from ITU-T, in particular LS 26 from December 2008. LS 26 describes
the actions that ITU-T is taking to completely replace T-MPLS with
MPLS-TP. That's the meaning of "deprecate". The remainder of Loa's
original paragraph merely repeats what was in LS 26 regarding the
process. So I support leaving that particular paragraph as is.

Thanks,
Andy

On Thu, Feb 5, 2009 at 12:57 PM, Stewart Bryant <[email-masked]> wrote:
>>>                                       email:  [email-masked]

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Thu, 5 Feb 2009 20:59:23 +0100

Tom,

I fully concur with your readout below as to  the call for clarity,and to further summarize:

1. TMPLS is NOT MPLS-TP;  TMPLS is NOT MPLS.

2. Deprecating to so called "TMPLS standards in force" is confusing and  disruptive to the industry.

3. MPLS-TP is NOT an evolution of TMPLS nor is it "TMPLSv2"

Best/m

Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer

-----Original Message-----
From: [email-masked] on behalf of Thomas Walsh
Sent: Thu 2/5/2009 10:31 AM
To: Adrian Farrel; Ross Callon; BUSI ITALO; Loa Andersson; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Tom

Behalf
MPLS-
T-
MPLS-

---

From: George Swallow <[email-masked]>
Date: Thu, 05 Feb 2009 15:31:43 -0500

Tom -

Well said!

...George

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 05 Feb 2009 23:21:08 +0100

All,

I support the proposed changes.

They show that IETF endorses the agreement reached in the SG15
WP3 plenary meeting in december 2008 where members of the JWT
and IETF were present.

These agreements are documented in TD71R1/WP3, the "Report of
the activities of the Ad hoc group and the JWT on T-MPLS" from
"Co chairs Ad hoc on T-MPLS and the JWT (Joint Working Team)"
http://www.itu.int/md/T09-SG15-081201-TD-WP3-0075/en

And also in the WP3 meeting report TD51/PLEN section 3.1.2
and illustrated in Figure 1. This report was agreed in the
the closing plenary of SG15.
http://www.itu.int/md/T09-SG15-081201-TD-PLEN-0051/en

Also the charter text of the involved questions mention
revision of G.81xx recommedations.

Regards, Huub.

================

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Thomas Walsh <[email-masked]>
Date: Thu, 5 Feb 2009 17:32:11 -0500

Ross,

To your point on rewording the third dashed item in Loa's original draft
of the liaison.

>       it is not practical for the IETF to comment on them.

First, no T-MPLS contribution should ever be accepted in SG 15.  If a
contributor submits a T-MPLS contribution it should not be addressed.
T-MPLS has been terminated in ITU-T.

What is the point of this bullet?  Is it to ask for coordination with
IETF if MPLS-TP contributions are submitted to ITU-T? 

I imagine the only contributions that should be submitted to ITU-T on
MPLS-TP would concern (1) requirements (soon to be finished anyway) or
(2) text for new draft Recommendations on MPLS-TP in ITU-T.  I can
clearly see the need for coordination with IETF on text for the new
drafts.

Anything else?

Tom

Behalf
> Of Ross Callon
> Sent: Wednesday, January 28, 2009 7:51 AM
MPLS-

---

From: Thomas Walsh <[email-masked]>
Date: Thu, 5 Feb 2009 17:33:45 -0500

Yes, this is a very useful clarification from Greg.  

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Mirsky
Sent: Monday, February 02, 2009 7:21 AM
To: Ross Callon
Cc: [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-TP

Ross,
my understanding is that the work on T-MPLS, including review of any new
contributions, to be discontinued at ITU-T. Thus IETF might expect that
no new contributions on T-MPLS would be accepted in SG or Question
meetings. I think that the liaison is trying to express that and
encourage ITU-T to finalize MPLS-TP requirements as soon as possible. If
my understanding is correct, then I'd use your version but make the
sentence a bit shorter:
-    We also see that there is a need to coordinate between our two
     organizations so that T-MPLS related contributions to the ITU-T
     are not accepted into SG or Question meetings.

Regards,
Greg

On Wed, Jan 28, 2009 at 10:51 AM, Ross Callon <[email-masked]>
wrote:

Ross

-----Original Message-----

All,

/Loa
--

Loa Andersson

                                      email:

---

From: Thomas Walsh <[email-masked]>
Date: Thu, 5 Feb 2009 18:24:12 -0500

Here are my promised comments on Italo's changes to Loa's original text:

(1) 
First Paragraph, Italo added this text:
[Italo]
<Your recognition of the considerable progress made on transition work
from ITU-T T-MPLS to IETF MPLS-TP technology is very encouraging as well
as the proposals that have been adopted for the transition and progress
to happen at ITU-T.>

[Tom]
I noticed ITU-T also used the word transition in their most recent
liaison.  We are not in a transition period here. MPLS-TP is not an
evolution of or transition from T-MPLS but a new specification
altogether.  

Calling the agreements between ITU-T and IETF a transition from T-MPLS
to MPLS-TP again confuses the industry and we must correct that.
Obviously I don't agree with the proposed change. 

(2) 
Second Paragraph, Italo deleted the following from the original:
[Italo]
<We find it very encouraging that you have initiated the process to
deprecate the existing T-MPLS Recommendations and that you will
discontinue the use of the T-MPLS acronym and concepts.>

[Tom]
I can not accept the deletion proposed by Italo.  Based on previous
comments from IETF by liaison to ITU-T that T-MPLS Recommendations are
not MPLS-Technology (December 2008) and are a mutual danger to the
Internet and Transport Networks (July 2007) along with the unapproved
use of MPLS Ethertype, IETF should express an expectation that the steps
initiated thus far by ITU-T will lead to the deprecation of current
in-force T-MPLS Recommendations.  

T-MPLS should not to be represented as a pre-MPLS-TP specification. The
right action for ITU-T to undertake is publish the new MPLS-TP
Recommendations and remove the current in-force T-MPLS Recommendations. 

(3)
[Tom]
Finally, I do not support the remaining text changes proposed by Italo's
mark ups, especially the rewriting of the three dashed items.  Loa's
original text (with the appropriate clarification to dash item 3
suggested by Ross, Gary, others) is clearly the information IETF needs
to receive from ITU-T in a timely manner. 

Tom

Behalf
> Of BUSI ITALO
> Sent: Thursday, February 05, 2009 4:39 AM
MPLS-

---

From: Thomas Walsh <[email-masked]>
Date: Thu, 5 Feb 2009 18:45:02 -0500

Andy,

This is an interesting point that you raise and I think it is what many
*assumed* ITU-T meant in LS 26.

But the continuing objection by some on this list to stating in plain
English that ITU-T will deprecate T-MPLS Recommendations, leads to
another conclusion.  

If ITU-T only supersedes the existing T-MPLS Recommendations with the
new MPLS-TP Recommendations, then ITU-T has not deprecated T-MPLS at
all.  T-MPLS remains on the ITU-T web site as an earlier implementation.
There are numerous examples of this with ITU-T Recommendations where
earlier versions may still be deployed by some networks. 

I believe the IETF intent and expectation was deprecation and not
superseding of T-MPLS.  Otherwise it does appear that MPLS-TP is only an
update to T-MPLS.  

PLEASE NOTE:
The warning in LS26 calling MPLS-TP the "next update" of the T-MPLS
recommendation also implies MPLS-TP is only an update. 

It is now time to confront the issue once and for all regarding
deprecation of the existing T-MPLS Recommendations. 
 
So let's make it clear using plain English in the reply to ITU-T LS26
that deprecation is what is required.

Tom

Behalf
> Of Andrew G. Malis
> Sent: Thursday, February 05, 2009 11:23 AM
> To: BUSI ITALO
> Cc: [email-masked]
MPLS-
> > place the first week in Geneva - we have too much
<https://ciscosupport.webex.com/ciscosupport/j.php?ED=107380702&UID=1028
66
> 7352&PW=15c5610f0702100f>
> >
> > BUSI ITALO wrote:
> >>
> >> Loa,
> >>> Subject: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-
> [email-masked]
---------------------------------------------------------------------
> ---

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 06 Feb 2009 08:20:07 +0000

I agree with the statements below, we need closure on
this, otherwise we just continue to waste time and energy
on the political use of the English language.

We need that time and energy to solve the many technical
issues at hand, so let's close this down once and for all and
focus on the technical design of this important protocol.

Stewart

Thomas Walsh wrote:
>>>> In attachment my proposed changes to this LS in order to keep the
>>>>         
> text
>   
>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>           
> On
>   
>>>>> Behalf Of Loa Andersson

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Fri, 6 Feb 2009 09:42:00 +0100

Feng Huang,

Please re-read my email once again.

There are clear architectural differences.

Monique

Monique Jeanne Morrow

-----Original Message-----
From: HUANG Feng F [mailto:[email-masked]]
Sent: Fri 2/6/2009 12:40 AM
To: Monique Morrow (mmorrow); Thomas Walsh; Adrian Farrel; Ross Callon; BUSI ITALO; Loa Andersson; [email-masked]
Subject: RE: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP
 
Monique,
 
   I don't agree your 3 statements, please recall the history of MPLS-TP, it was born from T-MPLS in ITU and MPLS in IETF and MPLS-TP is standardized under cooperation between IETF and ITU..
 
B.R.
Feng Huang
Shanghai Bell

From: [email-masked] [mailto:[email-masked]] On Behalf Of Monique Morrow (mmorrow)
Sent: 2009?2?6? 3:59 AM
To: Thomas Walsh; Adrian Farrel; Ross Callon; BUSI ITALO; Loa Andersson; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Tom,

Best/m

Monique Jeanne Morrow

-----Original Message-----
From: [email-masked] on behalf of Thomas Walsh
Sent: Thu 2/5/2009 10:31 AM
To: Adrian Farrel; Ross Callon; BUSI ITALO; Loa Andersson; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Tom

Behalf
MPLS-
T-
MPLS-
text

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 06 Feb 2009 11:46:22 +0100

Tom, Stewart, Andy,

The term "deprecate" seems to have different interpretations.

1) deprecate means that the term "T-MPLS" in the ITU-T recommendations
G.8110.1, G.8112, G.8121, G.8131, draft G.8132, G.8151 will be replaced by
the term "MPLS-TP" in revised versions of those recommendations, leaving the
initial versions on the ITU-T web with status "Superseded".

2) deprecate means that the T-MPLS recommendations G.8110.1, G.8112, G.8121,
G.8131, draft G.8132, G.8151 will be made obsolete and there will be no
equivalent MPLS-TP recommendations created.

3) deprecate means that T-MPLS recommendations G.8110.1, G.8112, G.8121,
G.8131, draft G.8132, G.8151 will be made obsolete and removed from the
ITU-T web and revised versions of those recommendations in which the term
MPLS-TP is used will be created.

When looking at the agreements documented in TD51/PLEN
http://www.itu.int/md/T09-SG15-081201-TD-PLEN-0051/en, then I read in
section 3.1.2  
".	There is no agreement, or proposal to cancel or deprecate the T-MPLS
Recommendations currently in force. It was clarified that the statement that
ITU-T would "terminate work on current T-MPLS" should be understood to mean
that ITU-T will not undertake any further work to progress T-MPLS."
and in section 3.6.5
"Once the internet drafts have reached a reasonable level of stability the
editors will develop revised versions of the currently in force T-MPLS
Recommendations to reflect the IETF MPLS-TP architecture.".

This agreement excludes interpretation 2 from the possible set of
interpretations. It also unambiguously states that there is no agreement to
"deprecate the T-MPLS recommendations currently in force". In my
understanding of the agreements it is inappropriate to use the term
"deprecate" in the liaison.

This now leaves interpretation 1 and 3 as potential interpretations. The
difference is if the initial versions of these recommendations will stay on
the ITU-T web with status "Superseded".

The agreements documented in TD51/P do not describe that the initial
versions of the recommendations will be removed from the ITU-T web once the
revised version is available. Normal ITU-T procedure is to maintain earlier
versions with status "Superseded" when a revision becomes available. I
thought we discussed this item in Geneva and concluded that normal ITU-T
procedures would be followed. I would like to ask Steve Trowbridge who lead
the discussion in the opening plenary to provide further input so that we
can resolve this issue.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: vrijdag 6 februari 2009 9:20
To: Thomas Walsh
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

I agree with the statements below, we need closure on this, otherwise we
just continue to waste time and energy on the political use of the English
language.

We need that time and energy to solve the many technical issues at hand, so
let's close this down once and for all and focus on the technical design of
this important protocol.

Stewart

Thomas Walsh wrote:
> superseding of T-MPLS.  Otherwise it does appear that MPLS-TP is only 
> an update to T-MPLS.
>
> PLEASE NOTE:
>> After reading your proposed changes to the third liaison statement 
>> and the subsequent emails, I went back to re-read the incoming 
>> liaisons from ITU-T, in particular LS 26 from December 2008. LS 26 
>> describes the actions that ITU-T is taking to completely replace 
>> T-MPLS with MPLS-TP. That's the meaning of "deprecate". The remainder 
>> of Loa's original paragraph merely repeats what was in LS 26 
>> regarding the process. So I support leaving that particular paragraph as
is.
>>> The plan of record in the two organizations is to deprecate T-MPLS 
>>> and start again on an IETF-MPLS platform.
>>>
>>> Please lets not have a repeat of the debate that took place the 
>>> first week in Geneva - we have too much technical work to do.
>>>
>>> Stewart
>>>
>>>
>>>       
>>>>> We have two incoming liaisons on the cooperation, both are "For 
>>>>> Information@ and we strictly don't need to respond. They were sent 
>>>>> to the MEAD team and to the IETF/IAB respectively.
>>>>>
>>>>> There are however such progress in the cooperation, that I think 
>>>>> it is appropriate to respond that we noted and encourage the steps 
>>>>> they've taken. There are also a few things that we need to sort 
>>>>> out when it comes to exchange of information between the two 
>>>>> organizations.
>>>>>
>>>>> Comments are welcome, I intend to send this liaison early the week 
>>>>> of Feb 9.
>>>>>
>>>>> /Loa
>>>>> --
>>>>>
>>>>>
>>>>> Loa Andersson
>>>>>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 06 Feb 2009 11:53:15 +0100

Hi Andy,

You replied:

> MPLS-TP. That's the meaning of "deprecate". 

Because I am one of the editors of LS 26 I can tell you that the
word "update" is not and was not intended to be equivalent to
"depricate".
The other editor is native english, so there cannot be a
misunderstanding of the word used.

LS 26 also refers to the agreed JWT report and the WP3 report.
Both reports mention "revision" of current G.81xx recommendations
and don't mention depreciation.
Both reports are written in full cooperation of ITU-T and IETF.

So by keeping the word "depreciation" in the liaison response
the whole discussion will start again and as Stuart already
mentioned a few times, this is a waste of time and resources.
And also it confuses the industry about the position of the IETF.

Regards, Huub.
==============
> The remainder of Loa's

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 06 Feb 2009 11:43:29 +0000

Huub
> And also it confuses the industry about the position of the IETF.
There is no confusion about the position of the IETF. It
has quite clearly stated that T-MPLS is a potential
danger to the Internet and should not be deployed.

The most appropriate action under such circumstances is
deprecation of the protocol.

Stewart

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 6 Feb 2009 13:48:18 +0100

It seems that you are forgetting the discussion we had in December where
you have clarified that there was no proposal to deprecate the T-MPLS
Recommendations currently in force.

I did not think there was a need to repeat of the debate that took place
the first week in Geneva as I agree with you that we have too much
technical work to do.

The intent of my proposed text changes was to keep the LS text aligned
with the agreements we reached in December.

>From the way the debate is going on, it looks like there is the
intention to reopen the debate and delay the technical work.

This is very sad.

I oppose this intention and propose to reword the liaison in line with
what has been agreed.

Italo

> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Friday, February 06, 2009 12:43 PM
> To: [email-masked]

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 6 Feb 2009 05:19:08 -0800

Tom,

I agree with your comments.

Thanks,

John 

> From: Thomas Walsh [mailto:[email-masked]] 
> Sent: Thursday, February 05, 2009 3:24 PM
> To: BUSI ITALO; Loa Andersson; [email-masked]
> <Your recognition of the considerable progress made on 
> transition work from ITU-T T-MPLS to IETF MPLS-TP technology 
> is very encouraging as well as the proposals that have been 
> adopted for the transition and progress to happen at ITU-T.>
> 
> [Tom]
> I noticed ITU-T also used the word transition in their most 
> recent liaison.  We are not in a transition period here. 
> MPLS-TP is not an evolution of or transition from T-MPLS but 
> a new specification altogether.  
> 
> Calling the agreements between ITU-T and IETF a transition 
> from T-MPLS to MPLS-TP again confuses the industry and we 
> must correct that.
> <We find it very encouraging that you have initiated the 
> process to deprecate the existing T-MPLS Recommendations and 
> that you will discontinue the use of the T-MPLS acronym and concepts.>
> 
> [Tom]
> I can not accept the deletion proposed by Italo.  Based on 
> previous comments from IETF by liaison to ITU-T that T-MPLS 
> Recommendations are not MPLS-Technology (December 2008) and 
> are a mutual danger to the Internet and Transport Networks 
> (July 2007) along with the unapproved use of MPLS Ethertype, 
> IETF should express an expectation that the steps initiated 
> thus far by ITU-T will lead to the deprecation of current 
> T-MPLS should not to be represented as a pre-MPLS-TP 
> specification. The right action for ITU-T to undertake is 
> publish the new MPLS-TP Recommendations and remove the 
> current in-force T-MPLS Recommendations. 
> 
> (3)
> [Tom]
> Finally, I do not support the remaining text changes proposed 
> by Italo's mark ups, especially the rewriting of the three 
> dashed items.  Loa's original text (with the appropriate 
> clarification to dash item 3 suggested by Ross, Gary, others) 
> is clearly the information IETF needs to receive from ITU-T 
> in a timely manner. 
> 
> Tom
> 
> > > There are however such progress in the cooperation, that 
> I think it 
> > > is appropriate to respond that we noted and encourage the steps 
> > > they've taken. There are also a few things that we need 
> to sort out 
> > > when it comes to exchange of information between the two 
> > > organizations.
> > >

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 06 Feb 2009 17:30:25 +0100

Stewart,

> deprecation of the protocol.

Does this mean that you do not accept the agreement documented
in the JWT report and WP3 report and that all the time spent to
discuss these agreements is wasted and that you want to start
this discussion again.

So to quote you:
"we just continue to waste time and energy
on the political use of the English language.

We need that time and energy to solve the many technical
issues at hand, so let's close this down once and for all and
focus on the technical design of this important protocol."

Rgds, Huub.

---

From: Thomas Walsh <[email-masked]>
Date: Fri, 6 Feb 2009 12:08:32 -0500

Actually, I don't think there can be any other outcome but to deprecate.
The ITU-T recognized that IETF has design authority over the MPLS
protocol.  The leadership of both organizations has been quite clear on
this.  

The IETF has been very clear that T-MPLS is not an MPLS Technology and
can not use the MPLS Ethertype and other code points without the
approval of the MPLS Authority. 

IMHO, For ITU-T to not withdraw the offending protocol violates ITU-T
recognition of IETF authority in the matter.

Behalf
> Of Stewart Bryant
> Sent: Friday, February 06, 2009 3:43 AM
> To: [email-masked]
MPLS-

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 06 Feb 2009 17:34:52 +0000

Huub

I can see no logical linkage between my statement and your
deduction. Please will you explain it to me.

Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 6 Feb 2009 13:07:58 -0500

Hi Stewart,

Why is T-MPLS a potential danger to Internet? Does it cause any security
risk or attack?

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: February-06-09 6:43 AM
To: [email-masked]
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Huub

Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 6 Feb 2009 13:08:21 -0500

Hi Stewart,

Here is your own report:

 http://www.ietf.org/internet-drafts/draft-bryant-mpls-tp-jwt-report-00.txt

and here is what it says in your report that ITU-T agreed to do:

- Alignment of the current T-MPLS ITU-T Recommendations with MPLS-TP
      and,
- Termination of the work on current T-MPLS.

I can't see anywhere in the report the term or intention of deprecating.
Could you please clarify which part of this report indicates deprecating?

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: February-06-09 12:35 PM
To: [email-masked]
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Huub

Stewart

---

From: Thomas Walsh <[email-masked]>
Date: Fri, 6 Feb 2009 13:35:00 -0500

Actually, the liaison from IETF to the December 2008 SG 15 meeting did
request withdrawal of T-MPLS Recommendations as one solution. But,
apparently Italo is saying, this is not a formal proposal.  

My understanding (I wasn't there when this was discussed) is ITU-T
indicated their process would now allow withdrawing a Recommendation at
a single meeting but such action would need to span a couple of
meetings.  The interpretation, as noted by many on this list, was ITU-T
initiated the withdrawal process in December but would need time to
complete it.  

Apparently, according to some on this list, this is not a correct
interpretation of what ITU-T actually did in December. If that is the
case, Italo's intervention is very helpful in exposing the need for IETF
to be much more clear from this point on that T-MPLS Recommendations
must be withdrawn by ITU-T in order to remove the T-MPLS protocol from
the Internet.

Note from previous discussion superseding of T-MPLS with MPLS-TP or
calling MPLS-TP an update of T-MPLS does not remove the T-MPLS protocol
from the Internet.  

IETF has been very clear informing ITU-T that T-MPLS has no relationship
to MPLS Technology or to IETF MPLS-TP protocol. Yet, we now know that
the outcome of the SG 15 meeting has still not put to rest confusion in
the industry.  

IMHO, a liaison request from the MPLS Design Authority to ITU-T to
withdraw a non-conforming protocol should be sufficient for ITU-T
action. 

But, if a formal proposal is also required, the obvious next step is to
submit one as well. 

Tom

Behalf
> Of BUSI ITALO
> Sent: Friday, February 06, 2009 4:48 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
MPLS-

---

From: Thomas Walsh <[email-masked]>
Date: Fri, 6 Feb 2009 14:16:15 -0500

Sharam,

Please note I am not speaking for Stewart here, but this is my own
reaction to what you just said.

These are two necessary steps for sure and as far as I know are being
followed.  I see nothing inconsistent in what Stuart said.

Bottom line:  
The T-MPLS Recommendations were never submitted according to the IETF
change process and hence must be removed.

Monique and I just spent two weeks in January at ITU-T SG 13 and SG 11.
We generally found very good cooperation in their understanding that
they can not publish any change to IP or an MPLS protocol in a
Recommendation without following the IETF change process.  

The JWT agreement had two options (1) and (2).  

Option 2 would allow publication of T-MPLS Recommendations by ITU-T as
they currently exist as long as they remove the MPLS Ethertype.  

Option (1) does not allow use of the MPLS Ethertype in an ITU-T
Recommendation unless it's a protocol approved by IETF according to its
change process.  And this option conforms to the IETF Change process.

Please do not quote JWT agreements out of context. The JWT agreement
does not give ITU-T the right to ignore the IETF change process.  

ITU-T may freely use IETF approved protocols.  T-MPLS is not IETF
approved according to the change process. IETF has a right to ask for
these offending documents to be withdrawn.

Just my view,

Tom

Behalf
> Of Shahram Davari
> Sent: Friday, February 06, 2009 10:08 AM
> Cc: 'BUSI ITALO'; [email-masked]
MPLS-
Behalf
MPLS-

---

From: Thomas Walsh <[email-masked]>
Date: Fri, 6 Feb 2009 14:17:52 -0500

Hmmmm.  My opinion only.  T-MPLS did not follow the IETF change process
for one thing.

Behalf
MPLS-
Behalf
MPLS-

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 6 Feb 2009 14:42:40 -0500

Hi Tom,

What is wrong with option 2? Would that solve this issue?

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Walsh
Sent: February-06-09 2:16 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Sharam,

Bottom line:  

Just my view,

Tom

Behalf
MPLS-
Behalf
MPLS-

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 6 Feb 2009 14:50:33 -0500

Hi Tom,

AFAIK IETF doesn't remove an obsolete RFC from its server (e.g. RFC2598).
Are you then asking that ITU should remove obsolete recommendations from its
server.

Regards,
Shahram

-----Original Message-----

Sharam,

Bottom line:  

Just my view,

Tom

Behalf
MPLS-
Behalf
MPLS-

---

From: Thomas Walsh <[email-masked]>
Date: Fri, 6 Feb 2009 14:54:49 -0500

I think Option 2 would remove the problem but it also requires ITU-T to
stop using the MPLS Ethertype and change the name to something that does
not have MPLS in it.  But isn't that discussion moot.  

ITU-T rejected option 2.  So why go there now?

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Friday, February 06, 2009 11:43 AM
> To: Thomas Walsh; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-
Behalf
MPLS-
> > Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
http://www.ietf.org/internet-drafts/draft-bryant-mpls-tp-jwt-report-
> > 00.txt

---

From: Thomas Walsh <[email-masked]>
Date: Fri, 6 Feb 2009 14:58:29 -0500

In this case, I think so because it's an MPLS protocol that was not
approved through the IETF change process. Apparently people are using it
and therefore could appear on the internet.

> Sent: Friday, February 06, 2009 11:51 AM
MPLS-
> Are you then asking that ITU should remove obsolete recommendations
from
> its
Behalf
MPLS-

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Feb 2009 20:58:39 -0000

Shahram,

Trying to defuse a little...
I'm not sure that discussing the IETF behavior is entirely helpful, but for 
reference, RFCs that are "replaced" are marked in the RFC list as 
'obsolete.' RFCs that are no longer relevant are marked as 'historic' and 
RFCs that are considered harmful are obsoleted by a new RFC that describes 
how they are harmful.

What is at stake here is what is most helpful to the community at large. If 
a technology (e.g. T-MPLS) is being replaced by another technology (MPLS-TP) 
by wide consensus of the community (ITU-T and IETF) it is not helpful to 
allow people to think that the old technology is still valid and worth 
implementing. Doing so would mislead people into thinking that they there is 
community support for the technology. A new hardware company coming to the 
list of Recommendations might conclude that the industry supports the 
technology and might waste valuable development time pursuing the 
technology.

Given that the IETF has persuaded the ITU-T that T-MPLS should not be worked 
on further and should be replaced by MPLS-TP, it is dangerously misleading 
to leave the T-MPLS Recommendations "lying around".

The agreement in Geneva seems to have been a compromise. The IETF requested 
that the ITU-T should delete the existing T-MPLS Recommendations. The ITU-T 
has decided to leave the Recommendations in place until they are "replaced" 
by the v2 Recommendations that will move to MPLS-TP. It is debateable 
whether this replacement will mean that the v1 Recommendations are 
'deprecated', 'obsoleted', or merely 'replaced'. It would seem sensible, 
however, to note that G.xxxx v2 completely replaces G.xxxx v1 even if the 
latter remains available in the repository. Someone implementing or 
deploying G.xxxx would take the most recent version.

Actually, I had some reservations about the agreement in Geneva. It seems to 
me to be predicated on the ITU-T pulling its finger out and producing the v2 
Recommendations. As yet I have not seen even an editor's revisions of any 
one Recommendation (perhaps I have not looked in the right place?). If the 
ITU-T is not willing to produce this work I must assume that the JWT 
agreement is not backed by meaningful intent.

Cheers,
Adrian
----- Original Message ----- 
From: "Shahram Davari" <[email-masked]>
To: "'Thomas Walsh'" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: "'BUSI ITALO'" <[email-masked]>; <[email-masked]>
Sent: Friday, February 06, 2009 7:50 PM
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Fri, 6 Feb 2009 22:02:53 +0100

Yes indeed at the SG11/13 meeting this past january 2009:

There was indeed a spirit of intended cooperation between the ITU-T and the IETF as you, Tom, assert below esp in the context of  agreeing to adhere to IETF RFC 4775,

" Procedures for Protocol Extensions and Variations."

Best/m

Monique Jeanne Morrow

-----Original Message-----
From: [email-masked] on behalf of Thomas Walsh
Sent: Fri 2/6/2009 11:16 AM
To: [email-masked]; Stewart Bryant (stbryant); [email-masked]
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP
 
Sharam,

Bottom line:  

Just my view,

Tom

Behalf
MPLS-
Behalf
MPLS-

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Feb 2009 21:03:09 -0000

The main point here was accidental interworking.
Since T-MPLS uses the same Ethertype, it is hard to distinguish it from IETF 
MPLS.
Since it was felt that interworking might exist:
- because the same devices would be required to act in
   both type of network
- because some devices might have interfaces into both
  types of network at the same time
- because configuration errors might arise
it was felt that T-MPLS needed to be an interworking subset/superset of IETF 
MPLS.

There was also a lot of concern about knowing what you are buying. Is the 
box that calls itself an MPLS box actually capable of MPLS?

But this is rehearsing many liaisons and the work of the JWT. perhaps it 
would be best to go back and read the archive?

Thanks,
Adrian

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 6 Feb 2009 20:38:46 -0500

Hi Adrian and Tom,

I am personally in favour of deprecating T-MPLS, because I think the
industry needs one set of standard and having two will lead to confusion.
But  I don't think T-MPLS is dangerous for the public "Internet" (sine MPLS
or T-MPLS are not used in the public Internet) , and I also don't think not
following IETF change procedures is a convincing argument (because one might
come up with a valid protocol without following the IETF change process).

Best regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: February-06-09 3:59 PM
To: [email-masked]; 'Thomas Walsh'; [email-masked];
[email-masked]
Cc: 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Shahram,

Cheers,
Adrian

---

From: Ross Callon <[email-masked]>
Date: Fri, 6 Feb 2009 22:04:19 -0500

What do you mean that "MPLS is not used in the public Internet"?  MPLS
is very broadly used for support of multiple types of services,
including Internet IP service.  Many very large ISPs run their normal IP
datagram Internet services over MPLS in the core of their network.  If
MPLS were to break down (or more accurately be taken down due to
incompatibilities in standards), then you would not receive this email. 

It is **extremely** difficult to accurately predict what will happen if
different standards with known incompatibilities are deployed in the
same network.  What happens may depend upon specific deployment and
configuration details.  But deployment of standards with many known
incompatibilities has a very real possibility of causing entire networks
to fail.  It would not take that many tier 1 networks failing to stop
you and me from accessing popular Web sites, stop you and me from
exchanging email, and be the lead news story of major newspapers and
television news. 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shahram Davari
Sent: 06 February 2009 20:39
To: 'Adrian Farrel'; [email-masked]; Thomas Walsh;
[email-masked]; [email-masked]
Cc: 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-TP

Hi Adrian and Tom,

I am personally in favour of deprecating T-MPLS, because I think the
industry needs one set of standard and having two will lead to
confusion.
But  I don't think T-MPLS is dangerous for the public "Internet" (sine
MPLS
or T-MPLS are not used in the public Internet) , and I also don't think
not
following IETF change procedures is a convincing argument (because one
might
come up with a valid protocol without following the IETF change
process).

Best regards,
Shahram

-----Original Message-----

Shahram,

Trying to defuse a little...
I'm not sure that discussing the IETF behavior is entirely helpful, but
for 
reference, RFCs that are "replaced" are marked in the RFC list as 
'obsolete.' RFCs that are no longer relevant are marked as 'historic'
and 
RFCs that are considered harmful are obsoleted by a new RFC that
describes 
how they are harmful.

What is at stake here is what is most helpful to the community at large.
If 
a technology (e.g. T-MPLS) is being replaced by another technology
(MPLS-TP)

allow people to think that the old technology is still valid and worth 
implementing. Doing so would mislead people into thinking that they
there is

community support for the technology. A new hardware company coming to
the 
list of Recommendations might conclude that the industry supports the 
technology and might waste valuable development time pursuing the 
technology.

Given that the IETF has persuaded the ITU-T that T-MPLS should not be
worked

on further and should be replaced by MPLS-TP, it is dangerously
misleading 
to leave the T-MPLS Recommendations "lying around".

The agreement in Geneva seems to have been a compromise. The IETF
requested 
that the ITU-T should delete the existing T-MPLS Recommendations. The
ITU-T 
has decided to leave the Recommendations in place until they are
"replaced" 
by the v2 Recommendations that will move to MPLS-TP. It is debateable 
whether this replacement will mean that the v1 Recommendations are 
'deprecated', 'obsoleted', or merely 'replaced'. It would seem sensible,

however, to note that G.xxxx v2 completely replaces G.xxxx v1 even if
the 
latter remains available in the repository. Someone implementing or 
deploying G.xxxx would take the most recent version.

Actually, I had some reservations about the agreement in Geneva. It
seems to

me to be predicated on the ITU-T pulling its finger out and producing
the v2

Recommendations. As yet I have not seen even an editor's revisions of
any 
one Recommendation (perhaps I have not looked in the right place?). If
the 
ITU-T is not willing to produce this work I must assume that the JWT 
agreement is not backed by meaningful intent.

Cheers,
Adrian
----- Original Message ----- 
From: "Shahram Davari" <[email-masked]>
To: "'Thomas Walsh'" <[email-masked]>; <[email-masked]>; 

from 
Behalf

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 6 Feb 2009 23:25:18 -0500

Ross,

What I meant was that at Internet peering points (E-NNI) MPLS or T-MPLS are
not used. Off course a single ISP can use MPLS or T-MPLS in their own
network, but they are in full control of their own network and could make
sure incompatible protocols are not used or are used in a controlled manner.

Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ross Callon
Sent: February-06-09 10:04 PM
To: [email-masked]; Adrian Farrel; Thomas Walsh; [email-masked];
[email-masked]
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Ross

-----Original Message-----

Hi Adrian and Tom,

Best regards,
Shahram

-----Original Message-----

Shahram,

Cheers,
Adrian
----- Original Message ----- 
From: "Shahram Davari" <[email-masked]>
To: "'Thomas Walsh'" <[email-masked]>; <[email-masked]>; 

from 
Behalf

---

From: Thomas Nadeau <[email-masked]>
Date: Sat, 7 Feb 2009 09:57:55 -0500

> or T-MPLS are not used in the public Internet) ,

	Sharam,

	I am a little surprised by your assertion above that MPLS is not used  
in
the public Internet.  The reality is quite the contrary.  Perhaps you  
meant something
else or this is a typo?

	--Tom

> and I also don't think not

---

From: "Shahram Davari" <[email-masked]>
Date: Sat, 7 Feb 2009 10:10:33 -0500

Tom,

What I meant was that MPLS/T-MPLS are not used at Internet peering points
(E-NNI). Off course a single ISP can use MPLS or T-MPLS in their own
network, but they are in full control of their own network and could make
sure incompatible protocols are not used or are used in a controlled manner.

-Shahram

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: February-07-09 9:58 AM
To: [email-masked]
Cc: 'Adrian Farrel'; 'Thomas Walsh'; [email-masked];
[email-masked]; 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

	Sharam,

	I am a little surprised by your assertion above that MPLS is not
used  
in
the public Internet.  The reality is quite the contrary.  Perhaps you  
meant something
else or this is a typo?

	--Tom

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 7 Feb 2009 17:10:28 -0500

Sharam,

The IP/MPLS Forum has defined the MPLS Inter-Carrier Interconnect
Specification ( http://www.ipmplsforum.org/tech/IPMPLSForum19.0.0.pdf
). Just this past week I was in discussion with a large European-based
interconnect provider (they interconnect several hundred service
provider networks) that has customers interested in interconnecting
using this specification. I know of several other providers that have
also expressed interest.

In addition, Verizon (for one) has widely deployed MPLS in its public
and private IP backbone networks and intends to deploy MPLS-TP in its
transport network. We are extremely concerned with precluding any
potential harm through the accidental interconnection of IP/MPLS and
transport layer MPLS, either through operational or provisioning
error, or though physical misconnections in a CO. With MPLS-TP, we
know that potential harm can be precluded. We cannot be so sure with
T-MPLS as defined in the current recommendations.

Cheers,
Andy

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 08 Feb 2009 00:23:41 +0000

Sharam,

> sure incompatible protocols are not used or are used in a controlled manner.

Lots of things are controllable in theory. I have seen single vendor
networks collapse due to an implementation bug in a router. I have seen
parts of networks disappear from the routing table because copy & paste
errors have been made in the configuration. It is almost a certainty that
equipment will be misconnected at some point.

Whether it is a single operator or multiple operators is somewhat irrelevant
such consequences affect all our customers (directly or indirectly) and are
bad for the operator(s) and the industry. We have a responsibility in
standards to prevent as far as possible the likelihood of such things when
defining our standards.

Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Sat, 7 Feb 2009 19:27:20 -0500

Very well said, Andy!
Luyuan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andrew G. Malis
Sent: 07 February 2009 17:10
To: [email-masked]
Cc: [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-TP

Sharam,

In addition, Verizon (for one) has widely deployed MPLS in its public
and private IP backbone networks and intends to deploy MPLS-TP in its
transport network. We are extremely concerned with precluding any
potential harm through the accidental interconnection of IP/MPLS and
transport layer MPLS, either through operational or provisioning error,
or though physical misconnections in a CO. With MPLS-TP, we know that
potential harm can be precluded. We cannot be so sure with T-MPLS as
defined in the current recommendations.

Cheers,
Andy

On Sat, Feb 7, 2009 at 10:10 AM, Shahram Davari <[email-masked]>
wrote:
> Tom,
>
> What I meant was that MPLS/T-MPLS are not used at Internet peering 
> points (E-NNI). Off course a single ISP can use MPLS or T-MPLS in 
> their own network, but they are in full control of their own network 
> and could make sure incompatible protocols are not used or are used in
a controlled manner.
>> But  I don't think T-MPLS is dangerous for the public "Internet" 
>> (sine MPLS or T-MPLS are not used in the public Internet) ,
>
>        Sharam,
>
>        I am a little surprised by your assertion above that MPLS is 
> not used in the public Internet.  The reality is quite the contrary.  
> Perhaps you meant something else or this is a typo?
>
>        --Tom
>
>
>
>> following IETF change procedures is a convincing argument (because 
>> one might come up with a valid protocol without following the IETF 
>> change process).
>>
>> Best regards,
>> Shahram
>>
>> Behalf Of Adrian Farrel
>> I'm not sure that discussing the IETF behavior is entirely helpful, 
>> but for reference, RFCs that are "replaced" are marked in the RFC 
>> list as 'obsolete.' RFCs that are no longer relevant are marked as 
>> 'historic' and RFCs that are considered harmful are obsoleted by a 
>> new RFC that describes how they are harmful.
>>
>> What is at stake here is what is most helpful to the community at 
>> large. If a technology (e.g. T-MPLS) is being replaced by another 
>> technology
>> (MPLS-TP)
>>
>> by wide consensus of the community (ITU-T and IETF) it is not helpful

>> to allow people to think that the old technology is still valid and 
>> worth implementing. Doing so would mislead people into thinking that 
>> they there is
>>
>> community support for the technology. A new hardware company coming 
>> to the list of Recommendations might conclude that the industry 
>> supports the technology and might waste valuable development time 
>> pursuing the technology.
>>

>> misleading to leave the T-MPLS Recommendations "lying around".
>>
>> requested that the ITU-T should delete the existing T-MPLS 
>> Recommendations.
>> The ITU-T

>> 'deprecated', 'obsoleted', or merely 'replaced'. It would seem 
>> sensible, however, to note that G.xxxx v2 completely replaces G.xxxx 
>> v1 even if the latter remains available in the repository. Someone 
>> implementing or deploying G.xxxx would take the most recent version.
>>

>> any one Recommendation (perhaps I have not looked in the right 
>> place?).
>> If the
>>> from its server.
>>> Behalf Of Thomas Walsh
>>> These are two necessary steps for sure and as far as I know are 
>>> being followed.  I see nothing inconsistent in what Stuart said.
>>>
>>> Bottom line:
>>> The T-MPLS Recommendations were never submitted according to the 
>>> IETF change process and hence must be removed.
>>>

>>> Option 2 would allow publication of T-MPLS Recommendations by ITU-T 
>>> as they currently exist as long as they remove the MPLS Ethertype.
>>>
>>> Recommendation unless it's a protocol approved by IETF according to 
>>> its change process.  And this option conforms to the IETF Change 
>>> process.
>>>

>>> approved according to the change process. IETF has a right to ask 
>>> for these offending documents to be withdrawn.
>>>
>>> Just my view,
>>>
>>> Tom
>>>
>>>
>>>>>> There is no confusion about the position of the IETF. It has 
>>>>>> quite clearly stated that T-MPLS is a potential danger to the 
>>>>>> Internet and should not be deployed.
>>>>>>
>>>>> Does this mean that you do not accept the agreement documented in 
>>>>> the JWT report and WP3 report and that all the time spent to 
>>>>> discuss these agreements is wasted and that you want to start this

>>>>> discussion again.

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 8 Feb 2009 07:13:53 -0500

Hi Andy,

Thanks for your valuable input. However, it seems that we are not talking
about the same scenario, which is MPLS peering for the Public Internet.

Best regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andrew G. Malis
Sent: February-07-09 5:10 PM
To: [email-masked]
Cc: [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Sharam,

Cheers,
Andy

MPLS-TP
>> one might
>> but for
>> large. If
>> to the
>> sensible,
>>> as

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 08:10:17 +0100

Ben,

Y.1711 OAM is in the networks today and I doubt if operators that have it
will remove this equipment. The initial T-MPLS equipment has been using a
subset of the Y.1711 OAM, and I doubt if operators that have such initial
T-MPLS equipment will remove it from their networks. RFC3429 supports Y.1711
OAM. 

RFC1619 (PPP over SONET/SDH) caused serious interworking problems in the
SDH/SONET networks. It got replaced by RFC2615, but RFC1619 was never
removed from the IETF website.

As such, I don't see any advantage or reason for ITU-T to remove the initial
T-MPLS recommendations from their website after revisions of those
recommendations have been added that describe MPLS-TP.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: zondag 8 februari 2009 1:24
To: [email-masked]; Thomas Nadeau
Cc: 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Sharam,

On 07/02/2009 15:10, "Shahram Davari" <[email-masked]> wrote:
> and could make sure incompatible protocols are not used or are used in a
controlled manner.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 9 Feb 2009 02:41:53 -0500

Maarten,

	What do you mean by "in the networks today"?  As far as I know
there are still no real life deployments of 1711.

	--Tom

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 09 Feb 2009 08:55:30 +0100

Hi Tom,

> there are still no real life deployments of 1711.

Last year the IETF and ITU-T lists were used to ask potential
users of Y.1711 (i.e. label 14) to see if there were actual/active
users.
Based on the response we decided to use label 13 for MPLS-TP OAM.

Regards, Huub.

==============

---

From: "Nadeau,TD,Tom,DMF R" <[email-masked]>
Date: Mon, 9 Feb 2009 08:04:44 +0000

That conclusion was based on the potential for confusion and overlap,  
not the widespread deployment.

Sent from my iPhone

On Feb 9, 2009, at 7:55 AM, "Huub van Helvoort" <[email-masked]>  
wrote:

>>> On Behalf

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 09:13:35 +0100

Stewart,

RFC1619 has been proven to be a danger for the SDH/SONET networks (i.e.
serious problems occurred in the network), which is much worse then just a
"statement". Nontheless, RFC1619 is still on the IETF website.

Why is RFC1619 not deprecated (i.e. removed from the IETF website)?

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: vrijdag 6 februari 2009 12:43
To: [email-masked]
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Huub
>
> So by keeping the word "depreciation" in the liaison response the 
> whole discussion will start again and as Stuart already mentioned a 
> few times, this is a waste of time and resources.
There is no confusion about the position of the IETF. It has quite clearly
stated that T-MPLS is a potential danger to the Internet and should not be
deployed.

The most appropriate action under such circumstances is deprecation of the
protocol.

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 09:42:16 +0100

Adrian,

> As yet I have not seen even an editor's revisions of any one
Recommendation
> (perhaps I have not looked in the right place?). If the ITU-T is not
willing
> to produce this work I must assume that the JWT agreement is not backed by
> meaningful intent.

I do not understand why you write "if the ITU-T is not willing...". You have
attended the SG15 meeting and agreed with its report, which states in
section 3.6.5:

"Once the internet drafts have reached a reasonable level of stability the
editors will develop revised versions of the currently in force T-MPLS
Recommendations to reflect the IETF MPLS-TP architecture.  The editors
should consult with the appropriate IETF WG chairs to determine when (and
which aspects) of the internet drafts are stable enough to allow drafting
activities to proceed as early as possible.  These revised Recommendations
will refer to the technology as MPLS-TP.  Work on these revised
Recommendations will be advanced by correspondence and at a proposed interim
meeting (TD55/PLEN).  The editors are requested to have draft text available
at least one month before the interim meeting (i.e. May 1st) to allow other
participants to review the drafts and provide contributions to refine the
text."

The editors of the T-MPLS recommendations should develop revised versions
once the internet drafts have reached a reasonable level of stability. I am
not sure if there is any draft that has reached this level at this point in
time. 

Nonetheless as editor of G.8112 I have already started the revision process,
but have kept the number of changes to the absolute minimum so far. I.e. I
have replaced "T-MPLS" by "MPLS-TP", "TTM" by "MTM" and "TM" by "MT" in the
latest draft revised G.8112 (WD47R1, Oct. 2007) document. 

I can share this very first MPLS-TP revised version of G.8112 with you
today, or could wait somewhat longer to include more changes. I expect that
the same changes can be made to G.8110.1, G.8121, G.8131, G.8151 at this
point in time. If it is helpful to make those changes and upload those
drafts then this can be done. Please let me know and I will upload my
initial revision.

Regards,
Maarten

-----Original Message-----
Sent: vrijdag 6 februari 2009 21:59

Shahram,

Cheers,
Adrian
----- Original Message -----
From: "Shahram Davari" <[email-masked]>
To: "'Thomas Walsh'" <[email-masked]>; <[email-masked]>;

> its change process.  And this option conforms to the IETF Change process.
>
>> >>> whole discussion will start again and as Stuart already mentioned 
>> >>> a few times, this is a waste of time and resources.
>> >> There is no confusion about the position of the IETF. It has quite 
>> >> clearly stated that T-MPLS is a potential danger to the Internet 
>> >> and should not be deployed.
>> >>
>> I can see no logical linkage between my statement and your deduction. 
>> Please will you explain it to me.
>>
>> Stewart
>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Feb 2009 08:57:30 -0000

Of course.

But RFC 1619 is marked as obsoleted by RFC 2615 in the list of RFCs.

A

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 09 Feb 2009 09:03:37 +0000

> Why is RFC1619 not deprecated (i.e. removed from the IETF website)?
Maarten the RFC you quote is 15 year's old and was declared obsolete
10 years ago.

The RFC index says the following:

1619 PPP over SONET/SDH. W. Simpson. May 1994. (Format: TXT=8893
     bytes) (Obsoleted by RFC2615) (Status: PROPOSED STANDARD)

2615 PPP over SONET/SDH. A. Malis, W. Simpson. June 1999. (Format:
     TXT=18708 bytes) (Obsoletes RFC1619) (Status: PROPOSED STANDARD)

... and in the RFC2615 itself

This document replaces and obsoletes RFC 1619.  See section 7
for a summary of the changes from RFC 1619.

Looking up the word obsolete in Miriam Webster

1 a: no longer in use or no longer useful <an obsolete word>
  b: of a kind or style no longer current : old-fashioned
     <an obsolete technology>

There seems little danger that anyone will seek to deploy
RFC1619 in a network, because the term obsolete seems to
tell the reader that that RFC1619 is broken.

One consistent approach might be to change the T-MPLS warning
text to:

This Recommendation will be obsoleted by a new Recommendation
that will declare T-MPLS obsolete, that will only describe
MPLS-TP and will include normative references to the MPLS-TP
RFCs under development to meet ITU-T transport requirements.

That would seem to be consistent with the IETF approach under
similar circumstances and is a true statement of the facts.

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 10:12:00 +0100

Adrian,

The initial T-MPLS recommendations will similarly be marked as "Superseded"
and not longer be "In Force". To me this is thus the same situation as we
have between RFC2615 and RFC1619, just the two SDOs use different
terminologies.

Regards,
Maarten

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: maandag 9 februari 2009 9:58
To: Maarten Vissers; [email-masked]; [email-masked]
Cc: 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Of course.

A

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 9 Feb 2009 10:15:35 +0100

So, the RFC was obsolted after 5 years from its publication (i.e. when
the new RFC was published).

If we stop this unuseful attack from IETF to ITU-T, we will all have
more time to undertake technical work.

As a consequence we will be able to publish a new version of ITU-T
Recommendations, that will make the existing ones Superseded, in much
less time than 5 years.

Italo

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Monday, February 09, 2009 10:04 AM
> To: Maarten Vissers
> Cc: [email-masked]; BUSI ITALO; [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 10:20:12 +0100

Stewart,

> There seems little danger that anyone will seek to deploy RFC1619 in a
> network, because the term obsolete seems to tell the reader that that
RFC1619 is broken.

I would expect the same to occur with a version of a Recommendation that is
"Superseded".

To me the term "Superseded" is the ITU-T equivalent of IETF's "Obsoleted".

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: maandag 9 februari 2009 10:04
To: Maarten Vissers
Cc: [email-masked]; 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Maarten Vissers wrote:
> serious problems occurred in the network), which is much worse then 
> just a "statement". Nontheless, RFC1619 is still on the IETF website.
>
Maarten the RFC you quote is 15 year's old and was declared obsolete 10
years ago.

This document replaces and obsoletes RFC 1619.  See section 7 for a summary
of the changes from RFC 1619.

There seems little danger that anyone will seek to deploy
RFC1619 in a network, because the term obsolete seems to tell the reader
that that RFC1619 is broken.

One consistent approach might be to change the T-MPLS warning text to:

This Recommendation will be obsoleted by a new Recommendation that will
declare T-MPLS obsolete, that will only describe MPLS-TP and will include
normative references to the MPLS-TP RFCs under development to meet ITU-T
transport requirements.

That would seem to be consistent with the IETF approach under similar
circumstances and is a true statement of the facts.

Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Feb 2009 09:46:21 -0000

Beats me why we are debating the finer points of the English language.

Deprecated
Obsoleted
Superseded

No-one would sensibly implement or deploy a standard that had any of these 
categorisations.

IMHO, no-one would sensibly implement or deploy a standard that they knew 
would soon be placed into any of these categories any time soon.

A

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 9 Feb 2009 11:01:36 +0100

Adrian,

I am not a native English speaker, but these terms have formal and
precise meaning within ITU-T and IETF. As a consequence, we need to use
the right term.

"In force" is the right term to call the status of existing T-MPLS
Recommendations today.

"Superseded" is the right term to call the status of currently existing
T-MPLS Recommendations when a new revised version, aligned with MPLS-TP,
will be approved.

The process to superseed an existing in-force Recommendation is called
"Revision" within ITU-T.

Using different terms does not improve mutual understanding expecially
when it is well know that the alternative term has a complete different
semantic within ITU-T.

Italo

> Sent: Monday, February 09, 2009 10:46 AM
> To: Maarten Vissers; [email-masked]
> RFC1619 in a
> > I would expect the same to occur with a version of a 
> Recommendation that 
> > is
> > "Superseded".
> >

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 11:29:09 +0100

Adrian,

> Beats me why we are debating the finer points of the English language.

The reason is the text in a draft liaison statement, which requires some
enhancements. 
The issue with the current text is terminology differences between the two
SDOs. 
Having the terminology of ITU-T clarified, I hope that it will now be easy
to enhance the text of the draft liaison statement.

Regards,
Maarten

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: maandag 9 februari 2009 10:46
To: Maarten Vissers; [email-masked]
Cc: 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Deprecated
Obsoleted
Superseded

A

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Mon, 9 Feb 2009 11:45:38 +0100

A few points here:

1. The industry deserves clarity and accountability in this line of discussion; and debating what the ITU-T means about deprecation; and what the IETF means by obsolete takes away from the bigger picture:  the strategic  standard that the industry is rallying on is MPLS-TP.

2. I just participated in a very productive SG13/11 meeting this past January -- as ITU-T-NGN liaison for the IETF/IAB; I know there is definitely an interest for both SDOS to collaborate together-- and certainly to avoid the level of disruption we are seeing around so called "TMPLS"

3. Adrian, to your point:

"IMHO, no-one would sensibly implement or deploy a standard that they knew 
would soon be placed into any of these categories any time soon."

<MM> Fully concur -- further it is irresponsible.

Best always/ monique

Monique Jeanne Morrow

-----Original Message-----
From: [email-masked] on behalf of Adrian Farrel
Sent: Mon 2/9/2009 1:46 AM
To: Maarten Vissers; Stewart Bryant (stbryant)
Cc: 'BUSI ITALO'; [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Deprecated
Obsoleted
Superseded

A

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 9 Feb 2009 11:49:43 +0100

Monique,
 
I agree with your points 1 and 2.
 
The big problem is that the LS does not improve clarify nor
collaboration.
 
Regarding point 3, this is a marketing and commercial issue that must be
kept outside the scope of the standard discussion.
 
Italo

	From: Monique Morrow (mmorrow) [mailto:[email-masked]] 
	Sent: Monday, February 09, 2009 11:46 AM
	To: Adrian Farrel; Maarten Vissers; Stewart Bryant (stbryant)
	Cc: BUSI ITALO; [email-masked]
	Subject: RE: [mpls-tp] liaisons to the ITU-T (3) the cooperation
on MPLS-TP

	A few points here:
	
	1. The industry deserves clarity and accountability in this line
of discussion; and debating what the ITU-T means about deprecation; and
what the IETF means by obsolete takes away from the bigger picture:  the
strategic  standard that the industry is rallying on is MPLS-TP.
	
	2. I just participated in a very productive SG13/11 meeting this
past January -- as ITU-T-NGN liaison for the IETF/IAB; I know there is
definitely an interest for both SDOS to collaborate together-- and
certainly to avoid the level of disruption we are seeing around so
called "TMPLS"

	"IMHO, no-one would sensibly implement or deploy a standard that
they knew
	would soon be placed into any of these categories any time
soon."

	Best always/ monique
	
	Monique Jeanne Morrow

	-----Original Message-----
	From: [email-masked] on behalf of Adrian Farrel
	Sent: Mon 2/9/2009 1:46 AM
	To: Maarten Vissers; Stewart Bryant (stbryant)
	Cc: 'BUSI ITALO'; [email-masked]
	Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation
on MPLS-TP
	
	Beats me why we are debating the finer points of the English
language.
	
	Deprecated
	Obsoleted
	Superseded
	
	No-one would sensibly implement or deploy a standard that had
any of these
	categorisations.
	
	IMHO, no-one would sensibly implement or deploy a standard that
they knew
	would soon be placed into any of these categories any time soon.
	
	A
	----- Original Message -----
	From: "Maarten Vissers" <[email-masked]>
	To: <[email-masked]>
	Cc: "'BUSI ITALO'" <[email-masked]>;
<[email-masked]>
	Sent: Monday, February 09, 2009 9:20
	Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation
on MPLS-TP

RFC1619 in a
Recommendation that
	> This document replaces and obsoletes RFC 1619.  See section 7
for a
	> summary
	> This Recommendation will be obsoleted by a new Recommendation
that will
	> That would seem to be consistent with the IETF approach under
similar

---

From: Thomas Walsh <[email-masked]>
Date: Mon, 9 Feb 2009 16:36:53 -0500

Martin, 

You are correct on the procedure regarding the revision of the ITU-T
drafts.  It was worked out through extensive discussion in Q12/15 and I
believe all the other relevant questions adopted the same procedure by
pointing to section 3.6.5.  

I don't see any reason to change that as the revisions depend on the
internet drafts being stable.  

Tom

> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, February 09, 2009 12:42 AM
[email-masked];
MPLS-
> > to produce this work I must assume that the JWT agreement is not
backed
> by
> > meaningful intent.
> 
> I do not understand why you write "if the ITU-T is not willing...".
You
> have
> once the internet drafts have reached a reasonable level of stability.
I
> am
> not sure if there is any draft that has reached this level at this
point
> have replaced "T-MPLS" by "MPLS-TP", "TTM" by "MTM" and "TM" by "MT"
in
Behalf
MPLS-
> I'm not sure that discussing the IETF behavior is entirely helpful,
but
and
describes
> What is at stake here is what is most helpful to the community at
large.
> a technology (e.g. T-MPLS) is being replaced by another technology
(MPLS-
> TP)
to
> implementing. Doing so would mislead people into thinking that they
there
the
misleading
> that the ITU-T should delete the existing T-MPLS Recommendations. The
ITU-
> T
sensible,
the
> Actually, I had some reservations about the agreement in Geneva. It
seems
> to
the
> v2
any
the
MPLS-
> > These are two necessary steps for sure and as far as I know are
being
> > The T-MPLS Recommendations were never submitted according to the
IETF
as
for
the
> >> >> There is no confusion about the position of the IETF. It has
quite
> >> > discuss these agreements is wasted and that you want to start
this
> >> I can see no logical linkage between my statement and your
deduction.

---

From: Thomas Walsh <[email-masked]>
Date: Mon, 9 Feb 2009 23:30:29 -0500

Martin,

There was no agreement in December to deprecate the Recommendations
because as it was explained to me, ITU-T can not do this in a single
meeting. 

As Italo indicated there needs to be a formal proposal.  So one can be
submitted.  

ITU-T has agreed to follow the IETF change process. 

Tom

> Sent: Friday, February 06, 2009 2:46 AM
> To: [email-masked]; Thomas Walsh; Steve Trowbridge
> Cc: [email-masked]
MPLS-
> the term "MPLS-TP" in revised versions of those recommendations,
leaving
> Recommendations currently in force. It was clarified that the
statement
> that
> interpretations. It also unambiguously states that there is no
agreement
> difference is if the initial versions of these recommendations will
stay
> on
> versions of the recommendations will be removed from the ITU-T web
once
Behalf
MPLS-
> We need that time and energy to solve the many technical issues at
hand,
> so
> let's close this down once and for all and focus on the technical
design
> of
> >> regarding the process. So I support leaving that particular
paragraph
> as
> is.
> >>
> >> Thanks,
> >> Andy
> >>
> >> On Thu, Feb 5, 2009 at 12:57 PM, Stewart Bryant
<[email-masked]>
> >>> first week in Geneva - we have too much technical work to do.
<https://ciscosupport.webex.com/ciscosupport/j.php?ED=107380702&UID=10
> > 28
week

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 10 Feb 2009 10:28:35 +0100

As a consequence saying that "ITU-T is not willing to produce this work
" is another inaccurate representation of the facts

Italo

> Sent: Monday, February 09, 2009 10:37 PM
> To: Maarten Vissers; Adrian Farrel; [email-masked]; 
> > "Once the internet drafts have reached a reasonable level 
> of stability
> the
> > at least one month before the interim meeting (i.e. May 
> 1st) to allow
> > other
> > participants to review the drafts and provide contributions 
> to refine
> the
> > text."
> > 
> > today, or could wait somewhat longer to include more 
> changes. I expect
> > that
> [mailto:[email-masked]] On
> > > Behalf Of Thomas Walsh
> > > Monique and I just spent two weeks in January at ITU-T SG 
> 13 and SG
> 11.
> [mailto:[email-masked]] On
> > > Behalf
> > >> Of Shahram Davari
> [mailto:[email-masked]] On
> > > Behalf
> > >> Of Stewart Bryant

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 10 Feb 2009 10:33:50 +0100

Andy,

T-MPLS provides powerful OAM tools to detect any misconfiguration errors
and prevent "accidental interconnection of IP/MPLS and transport layer
MPLS"

Italo

> From: Andrew G. Malis [mailto:[email-masked]] 
> Sent: Saturday, February 07, 2009 11:10 PM
> To: [email-masked]
> Cc: Thomas Nadeau; BUSI ITALO; [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 Feb 2009 10:15:16 -0000

Whoa there Dobbin!

If you must quote people out of context, please at lead quote whole 
subordinate clauses. Preferably whole sentences.

I said "If the ITU-T is not willing to produce this work I must assume that 
the JWT agreement is not backed by meaningful intent."

Sounds like an accurate statement.
- It is a statement of my predicted behaviour
- It is not (IMHO) a reasonable cause and effect

I understand that the ITU does not spit out working drafts in quite the same 
way as the IETF. The tendency being to cluster drafting around the interim 
meetings. However, in view of the Rapporteur's statement that he expects to 
see editor's revisions (presumably with meaningful content/changes?) before 
he will agree to the scheduling of an interim meeting, I would hope to see 
some work starting soon.

The debate about whether the I-Ds are stable is valid. If I was editing a 
new revision of a Recommendation, I would want to know that the I-Ds I 
depended on were about 75% stable before I started. But I don't think I 
would need over 95% stability until I was close to finished with my work.

Cheers,
Adrian

----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: "Thomas Walsh" <[email-masked]>; "Maarten Vissers" 
<[email-masked]>; "Adrian Farrel" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 10, 2009 9:28 AM
Subject: RE: [mpls-tp] liaisons to the ITU-T (3) the cooperation on MPLS-TP

Italo

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 10 Feb 2009 09:59:46 -0500

All, it appears that this thread has degenerated into a replay of the
discussions that we had in Geneva over the process that will be used to
implement the agreements reached by the JWT.  The agreements are fully
documented in the meeting report TD51/PLEN) and the report of the ad hoc
chairs (TD75r1/3).

This is not a productive use of our time.  Can we all please focus our
energy on addressing the outstanding technical issues so that we can
achieve the timetable established for the work i.e. stable RFCs and a
first draft of the revised Recommendation by May 1st 2009 leading to
consent of the revised Recommendations in October 2009.  Note that any
RFCs that are normatively referenced must be approved before approval of
the Recommendations.

Malcolm Betts
Co  chair ad hoc on MPLS-TP
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

---

From: Thomas Walsh <[email-masked]>
Date: Tue, 10 Feb 2009 12:01:16 -0500

Italo,

You speak of T-MPLS as though its alive and well.

Tom

Behalf
> Of BUSI ITALO
> Sent: Tuesday, February 10, 2009 1:34 AM
> To: Andrew G. Malis; [email-masked]
> Cc: [email-masked]
MPLS-
> > Specification (
http://www.ipmplsforum.org/tech/IPMPLSForum19.0.0.pdf
On
on
> > >> Given that the IETF has persuaded the ITU-T that T-MPLS should
not
> > >> be worked
> > >> however, to note that G.xxxx v2 completely replaces G.xxxx v1
even
> > >> if the
> > >> Recommendations. As yet I have not seen even an editor's
revisions
> > >> of any
> > >> one Recommendation (perhaps I have not looked in the right
place?).
on

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 12 Feb 2009 00:28:17 +0100

Italo, you speak of T-MPLS as if its the nirvana of networking. If  
its so well defined (and presumably functional) why are we bothering  
with MPLS-TP?

	--Tom

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 12 Feb 2009 12:31:01 +0100

Adrian,

In order to avoid further misunderstandings, it is worth clarifying that
I was not willing to quote your statements nor to say that you are
misrepresenting the facts.

You have expressed an opinion that I do not agree with. You have all the
rights to express your opinion and I have all the rights to disagree
with it.

The problem I was trying to address is that in the past opinions like
yours were interpreted as statements of facts by many sources.

My intention was to make crystal clear that such a statement of facts is
inaccurate. The quotes were intended to represent the statement of facts
that is inaccurate.

I hope this clarifies my intention and apologize for having given the
wrong impression to have attacked your opinion (although I disagree with
it)

Italo

> Sent: Tuesday, February 10, 2009 11:15 AM
> To: BUSI ITALO; Thomas Walsh; Maarten Vissers; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> > > should consult with the appropriate IETF WG chairs to 
> determine when
> > (and
> > > Recommendations will be advanced by correspondence and at 
> a proposed
> > > interim
> > > Nonetheless as editor of G.8112 I have already started 
> the revision
> > > process,
> > > but have kept the number of changes to the absolute 
> minimum so far.
> > I.e. I
> > > the same changes can be made to G.8110.1, G.8121, G.8131, 
> G.8151 at
> > this
> > revisions of
> > place?). If

---

From: Loa Andersson <[email-masked]>
Date: Wed, 18 Feb 2009 11:44:58 +0100

Italo,

exactly what are you referring to here? Where are "the powerful
T-MPLS OAM tools" documented?

/Loa

-- 

Loa Andersson

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 18 Feb 2009 13:06:22 +0100

The first version of T-MPLS OAM tools are defined in ITU-T (approved and
in-force) Recommendation G.8112

G.8112 CV is powerful enogh to detect misconnections

Italo

> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Wednesday, February 18, 2009 11:45 AM
> To: BUSI ITALO
> Cc: Andrew G. Malis; [email-masked]
> >>>> Given that the IETF has persuaded the ITU-T that T-MPLS 
> should not
> >>>> be worked
> >>>>
> >>>> however, to note that G.xxxx v2 completely replaces 
> G.xxxx v1 even
> >>>> if the
> >>>> one Recommendation (perhaps I have not looked in the 
> right place?).
> >>>> If the

---

From: "David Allan" <[email-masked]>
Date: Wed, 18 Feb 2009 16:57:44 -0500

HI Italo:

Misbranching detection assumed the packet was received by a node that
implemented the standard and could determine on the basis of packet
contents that there was a problem. An OAM packet turning up somewhere
that does not understand would likely just be silently discarded...which
I believe is the scenario being discussed...

At a minimum, ability to detect inappropriate connection of T-MPLS and
MPLS together would require MPLS implementations be modified to alarm on
terminating a packet with an RFC 3429 label. Similarly T-MPLS would be
obliged to alarm on receipt of any IP packet with a 127/ address or some
similar heuristic. Unfortunately in both cases the point where
inappropriate interconnection was actually detected could be many hops
removed from the actual problem...

Not sure anyone is going to rush out to implement those
safeguards...what is more likely is that the T-MPLS trail simply appears
broken and is traced until the interconnect point is found (however I
believe that is going to be via MIB dumps given the state of G.8112)...
I'm not sure that qualifies as detection

D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BUSI ITALO
Sent: Wednesday, February 18, 2009 7:06 AM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [mpls-tp] liaisons to the ITU-T (3) the cooperation on
MPLS-TP

Italo

> exactly what are you referring to here? Where are "the powerful T-MPLS

> OAM tools" documented?

> >>>> 'obsolete.' RFCs that are no longer relevant are marked as 
> >>>> 'historic' and RFCs that are considered harmful are obsoleted by 
> >>>> a new RFC that describes how they are harmful.
> >>>>

> >>>> by wide consensus of the community (ITU-T and IETF) it is not 
> >>>> helpful to allow people to think that the old technology is still
> >> valid and worth

> >>>> sensible, however, to note that G.xxxx v2 completely replaces
> G.xxxx v1 even
> >>>> if the

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:04:49 -0000

Hi Dave....some general observations in-line: 

David Allan wrote 18 February 2009 21:58

> contents that there was a problem.
NH=> The key point here is that the CI of a layer network needs to be
consistent so that when traffic units end up in the wrong place their
functional fields can be parsed/interpreted in a consistent manner...and
this crucially includes the OAM as this should be generated/removed at
trail termination points (ie below the C/S adaptation function and
consistent for all clients).  In MPLS we don't even have consistent
label semantics.  Further, if one has a 'tool kit' of different OAM
solutions then this is even worse since we can't even assume the
consistent interpretation of this either when it is misdirected and
arrives at some arbitrary LSP trail termination point.....which is why I
favour consistent simple/sparse OAM for the always-on defect
detection/handling OAM.

> An OAM packet turning up somewhere
 NH=> The probability of (i) misforwarding vs (ii) black-holing in a
label-swapping co-ps network is a function of:
-	how many labels from the total label space are in use on each
link connection;
-	what the allocation policy is for labels.....if not 'random' in
some way but always allocated in a systematic/same way on each link
connection, then one could find a high probability of misforwarding even
when only a few labels are actually in use.
 
> terminating a packet with an RFC 3429 label.
NH=> True.  But a plea from history here.  This solution of using a
further header (with a special OAM alert label) over normal traffic is a
dreadful idea, since this means that OAM looks different to normal
traffic.  The OAM indicate flag should be an intrinsic part of the
normal traffic unit header because we need OAM and traffic units to look
as identical as possibble in the DP.  When I was drafting Y.1711 I could
not get this....the MPLS header is not functionally rich, and there was
no way to get access to the EXP and TTL fields.  There is actually no
excuse for this in MPLS-TP.  For one thing the TTL field should be
redundant is an properly designed co-ps mode transport network.  But if
this cannot be used then some other way must be found where both traffic
and OAM look the same.  And if you look at the proposal from John Drake
and myself this would work like this....as the OAM indicate flag would
use a different PID value than normal (client) traffic......though I
should also point out that the TTL and EXP bits are also largely
redundant (and quite rightly so) in this proposal (indicated by S=1 =>
ie BOS header always contains a PID function (in place of the normal
forwarding label for case S=0)).

> Similarly T-MPLS would be
NH=> If we have X different types of OAM to detect/handle defects then
each LSP trail termination point should also be ready and able to handle
X different OAM types arriving...as who knows what kind of traffic might
get misdirected to it.  But what a silly situation this would be!  This
is why I stated above that even if we have screwed-up on having
consistent CI wrt to what labels mean in MPLS, the OAM really needs to
be *identical* for all LSP cases...else you get into this combination
issue with the OAM.  This is why I don't like these references to 'OAM
tool kits' and lots of options for the always-on defect
detection/handling OAM....this needs to be simple/sparse and consistent
across all LSPs.

> I'm not sure that qualifies as detection
NH=> Quite Dave.  It has no need to be like this of course....but it
requires sticking rigidly to a few key arch principles from the outset
and not violating them.  I'll spare folks a list of what was done poorly
in MPLS....but it will be unforgivable if these same mistakes now also
appear in MPLS-TP.

regards, neil
> > >>>>> AFAIK IETF doesn't remove an obsolete RFC from its 
> server (e.g.
> > >>>>> RFC2598).

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:09:04 -0000

Hi Italo...I think its only fair to point out here that I spent a year
or so arguing for the use of a CV flow in MPLS ~7 years ago when I was
writing Y.1710/Y.1711.  At that time this 'powerful tool' came in for a
quite a bit of ridicule within IETF.  Of course this was quite
understandable, because if one breaks the rules of a connection (eg LDP
or PHP merging) then a simple CV OAM solution like Y.1711 can't be used
and one requires much more complex OAM.....and when one factors-in ECMP
this becomes almost proactively intractable IMO.  But OAM is the least
of the problems that such constructs create; fundamentally if one cannot
determinsitically manage resource because the rules of a connection are
broken then one has to design/operate the whole network to the single
most stringent client SLA in force.

Good OAM only follows good initial network/protocol design....so
understanding/getting the arch rules right for each of the 3 network
modes is crucially important...and they are *not* the same.  I am not at
all impressed by arguments from those folks that try and force some kind
of 'common functional solution' here...whether this is the myth of a
common CP running IP to Optics or those that advocate the same OAM for
all 3 network modes.  Sure we can re-use some components....but we
should do this wisely and from a position of proper technical
understanding and not dogma.

When we are dealing with the co-ps mode the most important thing to get
right is the rules of a connection....good OAM can then follow from
this.  And good OAM is not complex, it is just the opposite, ie
simple/sparse.

If you really want a best-case/lowest-cost solution for proactive
misconnectivity protection for the co-ps mode then it's a jolly good
idea to have a SA in each/every traffic unit (not just an adjunct OAM CV
flow)....just like one finds in PBB-TE for example.

regards, neil

> [mailto:[email-masked]] On Behalf Of BUSI ITALO
> Sent: 18 February 2009 12:06
> To: Loa Andersson
> Cc: [email-masked]
> > >>>> 'historic' and
> > >>>> helpful to
> > >>>> that the ITU-T should delete the existing T-MPLS 
> Recommendations.
> > >>>> The ITU-T