Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

From: Loa Andersson <[email-masked]>
Date: Sun, 23 Oct 2011 11:07:27 -0700

All,

I've taken time to re-read this draft over the weekend.

I still think it is well-written and extremely to the point;
it is in the interest of the IETF to publish. I support
publication of the draft.

Admittedly there are some issues around the e.g. the description of the
SDH/SONNET and the standardization of those technologies. Having
been involved in development of equipment that could run both
SDH and SONET, my understanding is that both when it comes to
chips and SW the split, even after the compromise, lead to higher
costs and longer schedules. we would have been in a better shape
with one standard also that time.

Maybe the authors should reflect the facts that Huub correctly point
out in his early mail on this thread, where he describes a situation
that was much worse than what is in the document.

/Loa

On 2011-09-26 12:42, The IESG wrote:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM'
>    <draft-sprecher-mpls-tp-oam-considerations-01.txt>  as an Informational
> RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-10-24. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>     The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
>     for use in transport network deployments. That is, MPLS-TP is a set
>     of functions and features selected from the wider MPLS toolset and
>     applied in a consistent way to meet the needs and requirements of
>     operators of packet transport networks.
>
>     During the process of development of the profile, additions to the
>     MPLS toolset have been made to ensure that the tools available met
>     the requirements. These additions were motivated by MPLS-TP, but form
>     part of the wider MPLS toolset such that any of them could be used in
>     any MPLS deployment.
>
>     One major set of additions provides enhanced support for Operations,
>     Administration, and Maintenance (OAM). This enables fault management
>     and performance monitoring to the level needed in a transport
>     network. Many solutions and protocol extensions have been proposed to
>     address these OAM requirements, and this document sets out the
>     reasons for selecting a single, coherent set of solutions for
>     standardization.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

-- 

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

---

From: Shane Amante <[email-masked]>
Date: Sun, 23 Oct 2011 21:54:40 -0600

I have taken the time to read this document and support it's publication.

From an operational PoV, the discussion in the Section 3 (particularly Sections 3.5 & 3.6) really hit home in that the costs of deploying a protocol to the network _and_ maintaining that protocol in the network are non-trivial.  And, ultimately, for a function as critical as OAM it absolutely needs to "just work" *everywhere*.

-shane

---

From: [email-masked]
Date: Mon, 24 Oct 2011 12:44:34 -0400

Loa,

As per my previous email , I have only seen one response to the 12 points 
that I raised, I do not agree with your assessment of this document.

Just to remind you of the points made by myself and several others on 
SONET and SDH:

SONET is a true subset of SDH:
The SDH standard supports both the North American and Japanese 24 
channel/T1/T3 hierarchy and the European 30 channel/E1/E4 based hierarchy 
within a single multiplexing structure.
SDH has no options for payloads at VC-4 (150Mb/s) and above. This has 
provided the basis for common solutions for packet based clients (GFP).
SDH allows T1/T3 services to be delivered in Europe and E1 services to be 
delivered in North America using a common infra structure.

A single standard that supported either the T1/T3 hierarchy or the E1 
hierarchy would not have been successful.

Deployment of a E1 only standard in North America would have required the 
conversion of all of the 24 channel/T1 deployed equipment and services 
into the 30 channel/E1 format. Similarly deployment of a T1 only standard 
in Europe would have required the conversion of all of the 30 channel/E1 
equipment and services into 24 channel/T1 format.  Clearly given the 
existing network deployments (in 1988) this was not a practical 
proposition.

Regards,

Malcolm

Loa Andersson <[email-masked]> 
Sent by: [email-masked]
23/10/2011 02:07 PM

To
[email-masked]
cc
The IESG <[email-masked]>, IETF-Announce <[email-masked]>
Subject
Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The 
Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational 
RFC

All,

/Loa

-- 

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