[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] [Last-Call] Tsvart last call review of draft-ietf-mpls-rmr-12
From: Colin Perkins <csp () csperkins ! org>
Date: 2020-10-04 8:44:50
Message-ID: D9FA1A91-E5F9-49F3-ADB2-13EDBAAB5C49 () csperkins ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Kireeti,
Apologies for not following-up on this earlier myself. These changes look to address \
my concerns.
Colin
> On 16 Sep 2020, at 15:52, Kireeti Kompella <kireeti.kompella@gmail.com> wrote:
>
> 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@ietf.org \
> <mailto:noreply@ietf.org>> 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@ietf.org <mailto:tsv-art@ietf.org> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class="">Hi Kireeti,<div class=""><br \
class=""></div><div class="">Apologies for not following-up on this earlier myself. \
These changes look to address my concerns. </div><div class=""><br \
class=""></div><div class="">Colin</div><div class=""><br class=""></div><div \
class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On 16 Sep 2020, at 15:52, Kireeti Kompella <<a \
href="mailto:kireeti.kompella@gmail.com" class="">kireeti.kompella@gmail.com</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" \
class=""><div class="">Hi Colin,</div><div class=""><br class=""></div><div \
class="">Sorry for the very belated response!</div><div class=""><br \
class=""></div><div class="">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.<br \
class=""></div><div class=""><br class=""></div><div class="">The nits in section 1 \
& 1.1 have also been fixed.<br class=""></div><div class=""><br \
class=""></div><div class="">Hopefully, all your concerns have been \
addressed.</div><div class=""><br class=""></div><div class="">Cheers,</div><div \
class="">Kireeti.<br class=""></div><div class=""><br class=""></div></div><br \
class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, \
2019 at 3:30 PM Colin Perkins via Datatracker <<a href="mailto:noreply@ietf.org" \
class="">noreply@ietf.org</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Reviewer: Colin Perkins<br class=""> Review \
result: Almost Ready<br class=""> <br class="">
This document has been reviewed as part of the transport area review team's<br \
class=""> ongoing effort to review key IETF documents. These comments were written<br \
class=""> primarily for the transport area directors, but are copied to the \
document's<br class=""> authors and WG to allow them to address any issues raised and \
also to the IETF<br class=""> discussion list for information.<br class="">
<br class="">
When done at the time of IETF Last Call, the authors should consider this<br \
class=""> review as part of the last-call comments they receive. Please always CC<br \
class=""> <a href="mailto:tsv-art@ietf.org" target="_blank" \
class="">tsv-art@ietf.org</a> if you reply to or forward this review.<br class=""> \
<br class=""> The draft describes how MPLS can be used to configure ring \
topologies,<br class=""> as is frequently used to provide resilience. This seems like \
a reasonable<br class=""> thing to do - indeed I'm surprised such a specification \
doesn't already<br class=""> exist. From a transport perspective, this looks \
reasonable, but I do have<br class=""> some comments:<br class="">
<br class="">
- The draft discusses resilience mechanisms, by which the ring can be<br class="">
used to protect from link failures. There is, however, no discussion of<br class="">
how to recover from loss of the various messages used to announce and<br class="">
manage the ring network. It may be that the protocol used to convey<br class="">
these messages provides appropriate reliability mechanisms and the<br class="">
draft just needs to reference and clarify that. However, if not, it would<br \
class=""> seem worth considering robustness to loss of the ring advertisement<br \
class=""> and maintenance messages.<br class="">
<br class="">
- Auto-discovery in Section 4 uses timers T1 and T2. It's not clear what<br class="">
is the timeout value for these timers, and whether their value needs to<br class="">
be statically chosen or somehow tuned based on the size of the network. <br class="">
<br class="">
- Similarly, Section 5 on Ring OAM specifies two timers. These have fixed<br \
class=""> values of 3.3ms and 1s. It's not clear why these values were chosen or \
why<br class=""> they are correct.<br class="">
<br class="">
Nits:<br class="">
- The Introduction talks about "transport networks". It's not clear what<br class="">
is meant by this, and there might be an alternative term that's clearer.<br class="">
<br class="">
- The last paragraph before Section 1.1 states: "The intent is not to<br class="">
construct rings in a mesh network, and use those for protection". I<br \
class=""> can't parse the grammar here – can you clarify?<br class="">
<br class="">
<br class="">
</blockquote></div><br clear="all" class=""><br class="">-- <br class=""><div \
dir="ltr" class="gmail_signature">Kireeti</div>
-- <br class="">last-call mailing list<br class=""><a \
href="mailto:last-call@ietf.org" class="">last-call@ietf.org</a><br \
class="">https://www.ietf.org/mailman/listinfo/last-call<br \
class=""></div></blockquote></div><br class=""></div></body></html>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic