| Hi Kireeti,
Apologies for not following-up on this earlier myself. These changes look to address my concerns.
Colin
Hi Colin,
Sorry for the very belated response!
Thank you for your review. All of your comments have been addressed in the -13 update; section 1.2 has a summary of the changes, marked with [TAR] for the Transport Area Review. Section 4.2 has updated text on timers; unfortunately, there are two typos here: one, this change was made in response to TAR, not SAD; two, the actual change was duplicated. Section 5 defers the value of the OAM timer to the OAM protocol being used.
The nits in section 1 & 1.1 have also been fixed.
Hopefully, all your concerns have been addressed.
Cheers, Kireeti.
On Tue, Nov 5, 2019 at 3:30 PM Colin Perkins via Datatracker < noreply@xxxxxxxx> wrote: Reviewer: Colin Perkins
Review result: Almost Ready
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
The draft describes how MPLS can be used to configure ring topologies,
as is frequently used to provide resilience. This seems like a reasonable
thing to do - indeed I'm surprised such a specification doesn't already
exist. From a transport perspective, this looks reasonable, but I do have
some comments:
- The draft discusses resilience mechanisms, by which the ring can be
used to protect from link failures. There is, however, no discussion of
how to recover from loss of the various messages used to announce and
manage the ring network. It may be that the protocol used to convey
these messages provides appropriate reliability mechanisms and the
draft just needs to reference and clarify that. However, if not, it would
seem worth considering robustness to loss of the ring advertisement
and maintenance messages.
- Auto-discovery in Section 4 uses timers T1 and T2. It's not clear what
is the timeout value for these timers, and whether their value needs to
be statically chosen or somehow tuned based on the size of the network.
- Similarly, Section 5 on Ring OAM specifies two timers. These have fixed
values of 3.3ms and 1s. It's not clear why these values were chosen or why
they are correct.
Nits:
- The Introduction talks about "transport networks". It's not clear what
is meant by this, and there might be an alternative term that's clearer.
- The last paragraph before Section 1.1 states: “The intent is not to
construct rings in a mesh network, and use those for protection”. I
can’t parse the grammar here – can you clarify?
-- Kireeti
-- last-call mailing list last-call@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/last-call
|
