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 <loa@xxxxx>
Sent by: ietf-bounces@xxxxxxxx 23/10/2011 02:07 PM |
|
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
> ietf@xxxxxxxx mailing lists by 2011-10-24. Exceptionally, comments may be
> sent to iesg@xxxxxxxx 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
> IETF-Announce@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf-announce
--
Loa Andersson email: loa.andersson@xxxxxxxxxxxx
Sr Strategy and Standards Manager loa@xxxxx
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf