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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-sprecher-mpls-tp-oam-considerations-01.txt Reviewer: Brian Carpenter Review Date: 2011-10-30 IETF LC End Date: 2011-10-24 IESG Telechat date: 2011-11-03 Summary: In good shape, but changes needed. -------- Comments: --------- I am rather surprised that this has not been updated, given the somewhat extensive Last Call discussions. I fundamentally support the document, but it clearly needs revision. 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 - at the minimum, they should become Appendices, and since some aspects have proved controversial, it might be better simply to delete them. > 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. > 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.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
