Telechat Review of draft-ietf-teas-gmpls-resource-sharing-proc-07
review-ietf-teas-gmpls-resource-sharing-proc-07-genart-telechat-worley-2017-01-23-00
Request | Review of | draft-ietf-teas-gmpls-resource-sharing-proc |
---|---|---|
Requested revision | No specific revision (document currently at 08) | |
Type | Telechat Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2017-01-31 | |
Requested | 2017-01-03 | |
Authors | Xian Zhang , Haomian Zheng , Rakesh Gandhi , Zafar Ali , Pawel Brzozowski | |
I-D last updated | 2017-01-23 | |
Completed reviews |
Rtgdir Early review of -05
by Christian Hopps
(diff)
Genart Last Call review of -06 by Dale R. Worley (diff) Genart Telechat review of -07 by Dale R. Worley (diff) Genart Telechat review of -08 by Dale R. Worley Secdir Telechat review of -08 by Liang Xia |
|
Assignment | Reviewer | Dale R. Worley |
State | Completed | |
Request | Telechat review on draft-ietf-teas-gmpls-resource-sharing-proc by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 07 (document currently at 08) | |
Result | Ready w/nits | |
Completed | 2017-01-23 |
review-ietf-teas-gmpls-resource-sharing-proc-07-genart-telechat-worley-2017-01-23-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-teas-gmpls-resource-sharing-proc-07 Reviewer: Dale R. Worley Review Date: 23 Jan 2017 IETF LC End Date: 17 Jan 2017 IESG Telechat date: 2 Feb 2017 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. There remain a few editorial items: 2. Conventions Used in This Document The reader is assumed to be familiar with the terminology in [RFC3209], [RFC3473], [RFC4872], [RFC4873] and [RFC4427]. That is a significant help to the reader, but it's also rather intimidating! Is there a way to point out that 4427 is specific to recovery? 3.1.1. 1+R Restoration Unlike a protecting LSP which is set up before the failure, a restoration LSP is set up per need basis, after the failure. Probably better to change "per need basis" to "when needed". 3.2. Resource Sharing By Restoration LSP "By" generally should not be capitalized in titles, as it is a preposition. +-----+ +-----+ | F +------+ G +--------+ +--+--+ +-----+ | | | | | +-----+ +-----+ +--+--+ +-----+ +--+--+ | A +----+ B +-----+ C +--X---+ D +-----+ E | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 3: Resource Sharing in 1+R Recovery Scheme [...] Nodes A and B reconfigure the resources to set up the restoration LSP by sending cross-connection command to the data plane. In the recovery scheme employing revertive behavior, after the failure is repaired, the resources on nodes A and B need to be reconfigured to set up the working LSP. The traffic is then reverted back to the original working LSP. It's not clear to me why nodes A and B are reconfigured and/or do the reconfiguring. Any "global" reconfiguring would be driven by the head-end A alone, I think. Any "local" reconfiguring would be done by C and possibly E. Though perhaps there is reconfiguring that must be done along the entire path, but that would be attributed to A, B, C, F, G, and E together. I suspect there is a trivial editorial error here... [END]