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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please see attached review.

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-sprecher-mpls-tp-oam-considerations-01.txt
Reviewer: Brian Carpenter
Review Date: 2011-09-28
IETF LC End Date: 2011-10-24
IESG Telechat date: 2011-11-03

Summary:  In good shape, some changes suggested.
--------

Comments:
---------

1. As this is a document of quite general interest, I'm sending this Gen-ART review
to the main IETF list too.

2. I strongly support the publication of this document, although I do have some
suggested changes mentioned below.

Open issues: 
------------

Please define "Transport" as used in this document. People immersed in ITU-T
thinking understand that this is not layer 4, but the usage is very confusing
to many IETF people.

>  This document is intended to explain why it would be
>  unwise to standardize multiple solutions for MPLS-TP OAM, and to show
>  how the existence of multiple solutions would complicate MPLS-TP
>  development and deployment making networks more expensive to build,
>  less stable, and more costly to operate.

Good... but then I suggest that Section 3 and Section 6 both need
a closing sub-section that summarizes the way in which they justify
"more expensive to build, less stable, and more costly to operate."

Also, I found that Sections 4 and 5 get in the way of the flow of
the argument - did you consider making them into Appendices?

> 3.4.  The Complexity Sausage
...
>  However, when we
>  drive OAM complexity out of one network element at the cost of
>  increased complexity at a peer network element we loose out
>  economically and, more importantly, we loose out in terms of the
>  reliability of this important network functionality.

I don't understand how this argues the case for having only one solution.
It seems quite orthogonal. The following paragraph is a powerful and
relevant argument, but quite different and nothing to do with sausage:

>  ...due to the need to ensure compatibility of an inter-
>  working function between the two solutions (in order to achieve
>  end-to-end OAM) we create a situation where neither of two disjoint
>  protocol developments is able to make technical advances.


> 3.5.  Inter-Working is Expensive and Has Deployment Issues
...
>  The IETF has, with good reason, a history of strongly opposing
>  proposals to inter-work protocols.

This sentence reads like a religious statement, so I would delete it.
The preceding arguments are already very strong, and Section 4 makes the
same point in an objective fashion.

> 3.7.  Migration Issues
>
>  Deployment of a technology that is subsequently replaced or obsoleted
>  often leads to the need to migrate from one technology to another.
>  Such a situation might arise if an operator deploys one of the two
>  OAM protocol solutions and discovers that it needs to move to use the
>  other one.

Suggested addition here:

   A specific case would be when two operators merge their networks, but
   are using different OAM solutions.

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]