Thank you Dale for the thorough review of the document. Please see the attached diff file with the changes.
Please see inline for the replies <RG> ..
On 2017-01-23, 4:09 PM, "Dale Worley" <worley@xxxxxxxxxxx> wrote:
Reviewer: Dale Worley
Review result: Ready with Nits
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?
<RG> Yes, added.
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".
<RG> Yes, edited.
3.2. Resource Sharing By Restoration LSP
"By" generally should not be capitalized in titles, as it is a
preposition.
<RG> Edited.
+-----+ +-----+
| 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...
<RG> Corrected the text. I made an error in the last update when addressing your comment.
Thanks,
Rakesh (for authors and contributors)
[END]
<<< text/html; name="Diff_ draft-ietf-teas-gmpls-resource-sharing-proc-07.txt - draft-ietf-teas-gmpls-resource-sharing-proc-08.html": Unrecognized >>>