MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design
RFC 6965

Note: This ballot was opened for revision 07 and is now closed.

(Adrian Farrel) Yes

(Jari Arkko) No Objection

Comment (2013-03-27 for -07)
No email
send info
I did not think Section 1.2 was very informative. A rewrite in a different style would have made it better. These last call comments from Russ Housley were also on Section 1.2:


I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document.

It currently says:

  In recent years, the urgency for moving from traditional transport
  technologies, such as SONET/SDH, TDM, and ATM, to new packet
  technologies has been rising. This is largely due to the fast growing
  demand for bandwidth, which has been fueled by the following factors:

Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives:

  Traditional transport technologies include SONET/SDH, TDM, and ATM.
  There is a transition away from these transport technologies to new
  packet technologies. In addition to the ever increasing demand for
  bandwidth, the packet technologies offer these advantages:

The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies.  The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets.

It seems like the only sentence that addresses this point in Section 1.2 is: "It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence."

(Richard Barnes) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2013-05-02)
No email
send info
Many thanks for addressing my concerns.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-03-26 for -07)
No email
send info
I tend to agree with Stephen's general sentiment regarding some marketing in the document. 
However, as the write-up mentions "This document has a strong support in the working group and has been well reviewed.", I will record "no objection"

(Stephen Farrell) No Objection

Comment (2013-03-22 for -07)
No email
send info
- The "transport" (packet transport) vs. "transport"
(TCP) terminology divergence screams out here, even from
the moment one starts reading the ballot writeup.  The
routing and transport ADs might want to do something about 
that sometime. (The transport ADs get 2x votes as to what to
do of course:-)

- Once I did start reading, my marketing-BS detectors
started firing big time. (See the specific comments
below.) To be honest, I think this kind of post-facto
justification marketing-spiel is mildly damaging to the
RFC series. Not enough to object, but enough to be

- 1.1, I dare you to invent expansions of 5G, 6G, 7G
etc.:-) And looking at this section, I don't believe all
the acronyms expanded are actually used, e.g. "AIS" seems
to occur exactly once in the document. There are also
seem to be acronyms that are expanded here that are used
exactly once which seems like a waste of space. And
lastly, expanding an acronym is not really the same as
defining a term, and this section does the former and not
the latter mostly.  So overall, this section seems not so
useful and more for forms sake or to make the document
look "more serious" both of which seem undesirable to
this reader.

- 1.2, "many legacy transport devices are approaching end
of life" - I'd love to see some references there, (since
I think that's an interesting fact, if its a fact) but
the phrase is also vague - do you mean the devices are
reaching end of life or the product lines are?

- 1.2, "MPLS family," "complements existing," "closes the
gap," "efficient, reliable" and "emerged as the next
generation transport technology of choice" all seem to me
to be purely marketing terms and are all are used within
one paragraph here. Phrases in subsequent paragraphs
outdo this one. IMO the best IETF marketing materials
involve code and/or technical detail of existing
deployment details and we're really not the best place
from which to launch this kind of text. (It turned me off
the rest of the document anyway fwiw, I'd never have read
the whole thing if I didn't have to ballot on it.)

- 2.1, "becoming inadequate," "too expensive to
maintain," without references those are merely truth by
blatent assertion. "a natural choice" also grates.

- 2.1, "most Service Provider's core networks are MPLS
enabled" seems to scream for a reference

- 2.1, "it reduces OPEX" seems similarly without factual
backing, "improves network efficiency" begs for a metric
and "reduces end-to-end convergence time" is talking
about something I'm sure, but its not clear what.

(At this point, I'm gonna stop calling out marketing
text. There's too much and it'd take too long. And it
turns out the only comments I would have had were
negative "we don't do marketing" things anyway;-)

(Brian Haberman) No Objection

Comment (2013-03-27 for -07)
No email
send info
I agree with Stephen's point that there doesn't seem to be any benefit in publishing this draft as an RFC.

Barry Leiba No Objection

Comment (2013-03-26 for -07)
No email
send info
I have to agree with Stephen that this really comes off more as a glossy brochure than as an IETF document.  But given the shepherd's contention that there's strong consensus in the working group to publish this, I'll say, "Mostly harmless."

(Ted Lemon) No Objection

(Martin Stiemerling) No Objection

Comment (2013-03-26 for -07)
No email
send info
I'm fine with the current text wrt to "transport" (packet transport) vs. "transport" (TCP), as at least in my understanding the difference is clear in the text context of this particular draft.

(Sean Turner) No Objection

Comment (2013-03-27 for -07)
No email
send info
I think this is harmless but it definitely felt like a glossy brochure.  When do I get an MPLS-TP t-shirt?

(Joel Jaeggli) Abstain

(Pete Resnick) (was Discuss) Abstain

Comment (2013-03-28 for -07)
No email
send info
This does sound like a lot of marketing fluff. *Why* did the WG think this was important to publish? Why was there "strong support in the WG"? Why is this "a reasonable contribution to the area of Internet engineering which it covers?"