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