Subject: My comments to the press about OAM for MPLS

From: Russ Housley <[email-masked]>
Date: Wed, 2 Mar 2011 10:15:05 -0500

I want the whole community to be aware of the comments that I made to the press over the past few days.  Last Friday, the ITU-T Study Group 15 decided to move forward with an OAM solution that is incompatible with the work being done in the IETF MPLS WG.  This is a breach of the agreement reached by the IETF and the ITU-T, which is published in RFC 5317.

The ITU-T press release about their action is here:
  http://www.itu.int/net/pressoffice/press_releases/2011/03.aspx

On behalf of the IETF, ISOC helped get the word out:
  http://isoc.org/wp/newsletter/?p=3287

The press is starting to cover the story:
  http://www.eweekeurope.co.uk/news/ietf-slams-itu-standards-vote-22392
  http://news.idg.no/cw/art.cfm?id=8B71BD58-1A64-6A71-CE24B4B4EB59B200

And, the ITU-T made a second announcement today:
  http://www.itu.int/ITU-T/newslog/Experts+Cast+Doubt+On+Jeopardize+Internet+Statement.aspx

I expect that there will be more press coverage of this unfortunate situation.

Thanks,
  Russ

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 2 Mar 2011 11:02:06 -0500

>  http://www.itu.int/ITU-T/newslog/Experts+Cast+Doubt+On+Jeopardize+Internet+Statement.aspx

With a very badly worded appeal to unnamed authority. Not a good response in my opinion.

Regards
Marshall

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Mar 2011 09:43:55 +1300

> With a very badly worded appeal to unnamed authority. Not a good response in my opinion.

Not to mention including the canard that the IETF unilaterally disbanded
"its group assigned to work with ITU" in 2009. Others with more detailed
knowledge can explain exactly why this is, er, a lie.

I am very disturbed by this development. ITU/IETF agreements go back a long
way - I believe the first ones were signed off by Vint Cerf, so long ago
that I would need to look in my paper archives to find the date. In fifteen
years of my personal experience, including my own dealings with three different
heads of ITU-T while I was IAB Chair and then IETF Chair, they have never
reneged on an agreement before.

   Brian Carpenter

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 03 Mar 2011 10:38:25 +0100

Hello Brian,

> knowledge can explain exactly why this is, er, a lie.

Here are some facts:
===================
I was member of the MEAD team.
A meeting of the MEAD team was scheduled to meet in Munich
12-14 October 2009. It was scheduled right after an ITU-T
SG15 plenary meeting (September 28 - October 9) because
MEAD team members attended that meeting too.

On Friday October 2nd an agenda was distributed for the MEAD
team for the meeting in Munich on the MEAD team list [email-masked].
On Monday October 5th an email was sent to [email-masked]
announcing the disbanding of the MEAD team, and that the
meeting in Munich should not be considered a MEAD team meeting.

The decision to disband the MEAD team was liaised to the ITU-T
on the same day (October 5).

Do I need to say more.

Regards, Huub.

-- 
*****************************************************************
                          我爱外点一七三一

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 3 Mar 2011 13:51:13 +0100

Huub,
Good that you mention that you were part of the design team! That is correct.
You were also part of the team that worked in the face-to-face MEAD team meeting in Stockholm, July 2009, on the design and the technical direction for OAM in MPLS-TP. You were part of the team that presented the outcome of the MEAD team meeting and their recommendations to the MPLS WG in Stockholm. The IETF has started working on the solution based on these recommendations! 
See the authors in http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm.  
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Thursday, March 03, 2011 11:38 AM
To: Brian E Carpenter
Cc: IETF
Subject: Re: My comments to the press about OAM for MPLS

Hello Brian,

Here are some facts:
===================

Do I need to say more.

Regards, Huub.

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Mar 2011 12:51:38 -0500

>> knowledge can explain exactly why this is, er, a lie.

It does not sound like the shutdown of the MEAD team was smooth.  However, the closure of a design team when their output is being handled by a working group is quite normal.

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Mar 2011 09:04:59 +1300

> It does not sound like the shutdown of the MEAD team was smooth.  However, the closure of a design team when their output is being handled by a working group is quite normal.

That's the point. A design team is always a short term mechanism and once it
reports back to the WG, it closes down. Not having been personally
involved, I can't judge whether the process was clear to those involved,
especially people with more experience in ITU-T than in the IETF.

Just so we are all talking about the same thing, here is the official
description from BCP 25 (RFC 2418):

"6.5. Design teams

   It is often useful, and perhaps inevitable, for a sub-group of a
   working group to develop a proposal to solve a particular problem.
   Such a sub-group is called a design team.  In order for a design team
   to remain small and agile, it is acceptable to have closed membership
   and private meetings.  Design teams may range from an informal chat
   between people in a hallway to a formal set of expert volunteers that
   the WG chair or AD appoints to attack a controversial problem.  The
   output of a design team is always subject to approval, rejection or
   modification by the WG as a whole."

In other words, what counts in the IETF process is the WG consensus,
not the design team consensus. There are cases where the WG refuses or
significantly changes the design team proposal; RFC 3246 and RFC 3248
make a good example.

    Brian

---

From: David Morris <[email-masked]>
Date: Thu, 3 Mar 2011 16:07:52 -0800 (PST)

On Thu, 3 Mar 2011, Russ Housley wrote:

> It does not sound like the shutdown of the MEAD team was smooth.
> However, the closure of a design team when their output is being handled
> by a working group is quite normal.

>From following this thread, it sounds like the wrong IETF organization
unit was used to interface to the ITU?

---

From: John E Drake <[email-masked]>
Date: Fri, 4 Mar 2011 07:00:37 -0800

Hi,

I think we should be sad, though, that Huub's feelings were hurt when the team was disbanded.

Here is the liaison to the ITU describing the disbanding of the design team: https://datatracker.ietf.org/liaison/593/.  Interestingly, I can't find a reply from the ITU.  This implies they didn't consider it important at the time.

The design team report (http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day.  I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15):

"The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures).  Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure.  These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP...

The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness."

Thanks,

John

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Thursday, March 03, 2011 12:05 PM
> To: Russ Housley
> Cc: IETF
> However, the closure of a design team when their output is being
> handled by a working group is quite normal.
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 Mar 2011 10:20:13 -0500

> From: [email-masked] On Behalf Of Huub van Helvoort
> 

Uh, yes.  There are three statements, all of which are in the passive
voice; they describe actions that were taken without describing what
persons took the actions and on what authority.  At this distance, I'm
not sure that it matters, but if you are trying to enlighten those of
us who were not involved in these events, leaving out all the *names*
and even *organizational roles* makes everything obscure.

Dale

---

From: Ross Callon <[email-masked]>
Date: Fri, 4 Mar 2011 12:28:56 -0500

I have been on several design teams over the years, such as one that produced the MPLS Architecture (RFC3031), and a different one that produced the L3VPN Framework Document (RFC4110). In each case the design team was ended when an early draft of the document had been produced and submitted to the working group. 

Once an Internet Draft is accepted as a WG document, then the document "belongs" to the WG, in the sense that the document gets updated based on WG consensus. In fact, in the rare situation that a document author refuses to make changes to a WG document in violation of clear WG consensus, then the WG chairs have the authority to remove the author and put in different authors. This is just normal IETF process. 

Thus closing a design team when its work has been completed (which means that an initial draft has been submitted to the WG) is normal IETF process. The work continues in the WG (as happened in this case). 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, March 04, 2011 10:01 AM
To: Brian E Carpenter; Russ Housley
Cc: IETF
Subject: RE: My comments to the press about OAM for MPLS

Hi,

Thanks,

John

Sent from my iPhone

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Mar 2011 19:16:38 -0000

Hello Dale,

> and even *organizational roles* makes everything obscure.

Naming names...

The agenda for the MEAD Team meeting was distributed by the chair of the MEAD
team, Loa Andersson.
The team was closed by the responsible AD (me) in consultation with the team
chair and my co-AD.
The liaison (which you can find in the IETF liaison repository, or direct at
https://datatracker.ietf.org/liaison/593) was sent by me.

Please note that closing a DT opens the work up to wider participation which
addressed a number of private gripes I had received about participation in the
MPLS-TP project. But also note that the main reason for closing the team was
that it had completed on its charter.

The liaison makes these points clearly, I think.

Thanks,
Adrian

---

From: "t.petch" <[email-masked]>
Date: Fri, 4 Mar 2011 18:36:59 +0100

----- Original Message -----
From: "Ross Callon" <[email-masked]>
To: "John E Drake" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>; "Russ Housley" <[email-masked]>
Cc: "IETF" <[email-masked]>
Sent: Friday, March 04, 2011 6:28 PM

> I have been on several design teams over the years, such as one that produced
the MPLS Architecture (RFC3031), and a different one that produced the L3VPN
Framework Document (RFC4110). In each case the design team was ended when an
early draft of the document had been produced and submitted to the working
group.
>
> Once an Internet Draft is accepted as a WG document, then the document
"belongs" to the WG, in the sense that the document gets updated based on WG
consensus. In fact, in the rare situation that a document author refuses to make
changes to a WG document in violation of clear WG consensus, then the WG chairs
have the authority to remove the author and put in different authors. This is
just normal IETF process.
>
> Thus closing a design team when its work has been completed (which means that
an initial draft has been submitted to the WG) is normal IETF process. The work
continues in the WG (as happened in this case).

I think it misleading to call MEAD a Design Team (whatever the acronym stands
for).

As described in, e.g., draft-andersson-mpls-tp-process

"   o  MEAD team (MPLS Interoperability Design Team): a temporary team
      with participants with experience of standards development for
      MPLS and transport networks.  The MEAD team is chartered to
      coordinate the development of MPLS-TP within the IETF and to
      coordinate the cooperation between the IETF and the ITU-T"
which goes on to say
"   o  MPLS-TP document - the following documents count as MPLS-TP documents:

      *  Internet Drafts that are coordinated by the MEAD team.
....."
and
" Once a document
   has become a Working Group document, consensus is decided by the
   WG chairs and the MEAD team chair jointly."

MPLS-TP modifies the IETF processes to give a greater say to
ITU-T in such matters as comments, consensus and last calls so it matters
what constitutes a MPLS-TP document, to which one answer
is whatever MEAD considers to be an MPLS-TP document.

(Those not so considered could then go into an IETF
Working Group which followed regular IETF processes).

Coming with an IETF background, I found this an abomination
and was relieved when MEAD disappeared.

That said, the issue at hand is not, IMO, the MEAD team.  It is the
standing in the IETF and in the ITU-T of
draft-bhh-mpls-tp-oam-y1731-06
Those familiar with IETF processes will know from its name the standing of
this I-D within the IETF in general, and in MPLS in particular.  Those
not familiar have been enlightened by the recent, clear and careful
liaisons of  Stewart Bryant to the ITU-T.  This is what the ITU-T
seem reluctant to accept.

The discussion of the merit of the approach in this draft has been just
as energetic since MEAD was disbanded as ever it was.

Tom Petch

> Here is the liaison to the ITU describing the disbanding of the design team:
https://datatracker.ietf.org/liaison/593/.  Interestingly, I can't find a reply
from the ITU.  This implies they didn't consider it important at the time.
> The design team report
(http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm),
with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG
has followed to this day.  I think the report is compelling evidence that the
claim that a packet transport network is an MPLS application that intrinsically
requires a different OAM solution is simply a lame ex post facto attempt to
justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15)
from December 2008 sourced by SG15):
>
> "The ITU-T accepts these recommendations and states that any extensions to
MPLS technology will be progressed via the IETF standards process using the
procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures).  Experts from the
ITU-T will assist the IETF in the development of RFCs that describe the
transport extensions by providing input to and review of the drafts as they are
progressed via the IETF standards process.. The ITU-T will develop new or
revised Recommendations that will allow IETF MPLS-TP to be integrated into the
transport network including integration with the existing equipment, and
operations infrastructure.  These Recommendations will make normative references
to the base IETF MPLS-TP technology and will be developed with input from and
review by experts from the IETF to ensure consistency with MPLS-TP...
>
> The ITU-T has accepted the proposals from the JWT and we look forward to
continuing the cooperative development of IETF MPLS to address the needs of the
transport network. We also believe that this resolution will fulfil the mutual
goal of improve the functionality of the internet and transport networks and
guaranteeing complete interoperability and architectural soundness."

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 5 Mar 2011 17:55:54 +0100

The IETF MPLS-TP design team has successfully achieved its objectives. 
The main requirements work were published and the two subsidiary
requirements documents (NM and OAM) were close to publication. 
The core work on the frameworks and solutions has started and were
progressing.
It was just natural to allow further work on MPLS-TP to continue using
the IETF normal process to streamline the process and allow open
participation by everyone in the industry. 
And as I indicated in previous mail, the design team worked on the
design of the OAM solution in the f2f meeting in Stockholm, July 2009,
and presented its recommendation to the MPLS WG in IETF 75. The
recommendations were accepted and the WG started working on the
solutions based on these recommendations.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Worley, Dale R (Dale)
Sent: Friday, March 04, 2011 5:20 PM
To: Huub van Helvoort; Brian E Carpenter
Cc: IETF
Subject: RE: My comments to the press about OAM for MPLS

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Mar 2011 10:09:57 -0500

Given the stiff formality of many of the messages on this topic, and the absence of
description of who did what and why, I suspect the problem is some sort of a split
regarding what approach (or which particular solution) should be taken in OAM for
MPLS.  And that the two factions were probably backed by different commercial interests.
And that one faction had the upper hand within the IETF and the other faction had
the upper hand within the ITU.  The former committee was to provide the ITU faction
with an official or de-facto veto power over the IETF output, so that the ITU faction's
agreement would be required for "IETF consensus".  Eventually, the IETF faction got sick
of the fact that they weren't going to convert the ITU faction to their solution, so the
veto arrangement was summarily terminated from the IETF side, and now the IETF faction
can reach "consensus".

So we will get two standards, one from the IETF and one from the ITU, and the winner
will be determined in the marketplace.  "The great thing about standards is that there
are so many to choose from!"

Dale

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 7 Mar 2011 18:51:43 +0100

Hi,
So far We did not see any justification for two competing solutions for
OAM in MPLS-TP. We also did not see what is really missing in the IETF
solution and why if something is missing it cannot be resolved in the
context of a single solution. IT is not clear why alternative solution
is needed. If enhancement is needed, I am sure the IETF would be happy
to enhance the solution. 
There is no justification to confuse the industry with two competing
solutions that are defined in two different organizations and may evolve
in different and inconsistent way and will not allow two MPLS
implementations (ITU and IETF) to co-exist in the same network. 
What is clear is that unfortunately this is NOT a technical discussion! 
The industry blessed the agreement between the ITU-T and the IETF and
considered it as such a good opportunity for the Industry, incorporating
together the expertise of both ITU and IETF organizations, avoiding
duplication and inconsistencies. 
The determination of an alternative solution in the ITU-T for OAM is in
contrary to the collaborative agreement between the ITU-T and the IETF. 
The IETF solution is progressing. The solution will satisfy the
transport requirements as were defined together with the ITU-T. Complete
interoperability and architectural soundness with MPLS/GMPLS will be
guaranteed. 
The ITU-T SG15 OAM solution will enter the Consultation period where
only Governments can respond. The document must be unopposed! The future
of the document is uncertain and the process can be very long! 
Instead of putting so much energy in this political arguments and in the
attempt to fragment the Industry, we could positively work together to
ensure that the solution we define fully and appropriately satisfies the
requirements. It is really a pity!
Best regards,
Nurit

-----Original Message-----
From: ext Worley, Dale R (Dale) [mailto:[email-masked]] 
Sent: Monday, March 07, 2011 5:10 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Huub van Helvoort; Brian E
Carpenter
Cc: IETF

Given the stiff formality of many of the messages on this topic, and the
absence of
description of who did what and why, I suspect the problem is some sort
of a split
regarding what approach (or which particular solution) should be taken
in OAM for
MPLS.  And that the two factions were probably backed by different
commercial interests.
And that one faction had the upper hand within the IETF and the other
faction had
the upper hand within the ITU.  The former committee was to provide the
ITU faction
with an official or de-facto veto power over the IETF output, so that
the ITU faction's
agreement would be required for "IETF consensus".  Eventually, the IETF
faction got sick
of the fact that they weren't going to convert the ITU faction to their
solution, so the
veto arrangement was summarily terminated from the IETF side, and now
the IETF faction
can reach "consensus".

So we will get two standards, one from the IETF and one from the ITU,
and the winner
will be determined in the marketplace.  "The great thing about standards
is that there
are so many to choose from!"

Dale

---

From: "t.petch" <[email-masked]>
Date: Mon, 7 Mar 2011 17:56:00 +0100

----- Original Message -----
From: "Worley, Dale R (Dale)" <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>; "Huubvan
Helvoort" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>
Cc: "IETF" <[email-masked]>
Sent: Monday, March 07, 2011 4:09 PM

absence of
faction got sick
solution, so the
> veto arrangement was summarily terminated from the IETF side, and now the IETF
faction

That is a very perceptive observation as a study of the e-mails contained in
http://www.ietf.org/mail-archive/web/mpls/current/msg05612.html
show, especially that of Jing Ruiquan (draft-bhh and Y.1731 being the basis of
the favoured ITU-T solution now presented in G.tpoam).

Tom Petch

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Mar 2011 13:02:49 -0500

________________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]

So far We did not see any justification for two competing solutions for
OAM in MPLS-TP. 
________________________________________

No doubt you are correct.

But I will note that this is the first message in which a participant stated clearly that the
essential issue is one of two competing solutions, rather than complaining about the
bureaucratic details of the wrangling between the two camps.  The important fact is not
the roiling of the surface of the murky waters, but the movements of the alligators
underneath.

Dale

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Mar 2011 16:17:06 -0500

Given the subject matter, I suspect that the issue has something to do with
net neutrality and the various parties attempting to spin on that particular
issue.

As with many of these layer 8+ issues, what is driving events is not
necessarily the actual capabilities of the technology so much as the
perceived capabilities.

This conversation is not just taking place in IETF. There are international
treaties which bind certain very large authoritarian states to co-operate to
prevent 'information terrorism' (aka free speech) and 'dominance of the
information infrastructure' (aka being the United States, Microsoft, Google,
etc.).

Now there was a time when the idea that the Internet or the Web might have
political implications was to be treated with derision and sarcasm. After
the past six weeks, the political dimension cannot be hidden any longer.

Col Gaddafi is currently murdering his own people for having the temerity to
oppose his misrule. I really don't think we can expect him to shrink from
violating a MUST condition in an RFC. Nor do I think we are going to see
major hardware vendors pass up sales because they will not implement
censorship or control mechanisms (they have not done so to date).

Much better to have a clean separation in my view and let all the folk with
the complicated hidden agendas go elsewhere.

-- 
Website: http://hallambaker.com/