Hi, Dan, Many thanks for this review!
Although you label these as not-shot-stoppers, they are very useful. Here’s a follow-up: You are correct, set-up states transitions are minimized or eliminated with S-BFD. However, it can be argued (and it was our initial thinking) that the state set-up is also part of the actual test. Therefore, the starting is the same for both, but it takes shorter for CC packets to flow though. Consequently, in that case, “and completing” is probably better. If you consider the state setup as not part of the test, then “and starting” can be slightly more precise, assuming the time actual CC packets are on the ether is the same. I think that “and completing” is safer, but can easily be persuaded to use “and starting” with some additional text explaining the actual gain. No change so far. Yes. Will update. I am adding also an Informational pointer to draft-ietf-bfd-seamless-ip. Basically added: “IPv4, IPv6, or MPLS based [seamless-ip] and other options are possible and can be defined in future documents.” Nit fixed in the working copy. Thanks again, do let me know if you have a strong preference and rational regarding #1. Thanks, — Carlos. > On Mar 29, 2016, at 7:26 AM, Romascanu, Dan (Dan) <[email protected]> wrote: > > 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 treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> >. > > Document: draft-ietf-bfd-seamless-base-08 > Reviewer: Dan Romascanu > Review Date: 2016/3/29 > IETF LC End Date: 2016/4/12 > IESG Telechat date: 2016/5/5 > > Summary: Ready with minor issues > > The document is well written and complete, but requires a good understanding > of BFD (RFC 5880) and of the use-cases (draft-ietf-bfd-seamless-use-case) > document. A few minor issues are listed below, it would be good to address > them, but none is a show-stopper. > > Major issues: > > Minor issues: > > 1. In the introduction I see the following: > > Ø One key aspect of the mechanism described in this document eliminates > the time between a network node wanting to perform a continuity test > and completing the continuity test. > > I am wondering if this is really what is intended. If I understand correctly, > S-BFD does not eliminate the continuity test but the set-up states > transitions before the continuity test starts. Would not that rather be ‘… > and starting the continuity test.’? > > 2. In the last paragraph of Section 5: > > Ø Note that incoming S-BFD control packets may be IPv4, IPv6 or MPLS > based. > > If these are the only three options I suggest that the text explicitly > specify this. If other options are possible or may be possible in the future > I suggest that the text also clarifies this > > Nits/editorial comments: > > 1. Second paragraph in Section 3: s/allocated toby a remote > node/allocated to by a remote node/
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
