Hi Murray, thank you for the review, comments, and helpful suggestions. Please find my answers and notes below tagged by GIM>>.
Regards, Greg On Wed, Dec 16, 2020 at 9:48 PM Murray Kucherawy via Datatracker < nore...@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-bess-mvpn-fast-failover-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I concur with Barry's point about the definitions in Section 2.2. > > I can't quite parse the first sentence of Section 3.1.1. Maybe this will > help: > > OLD: > > A condition to consider that the status of a P-tunnel is Up is that > the root of the tunnel, as determined in the x-PMSI Tunnel attribute, > is reachable through unicast routing tables. > > NEW: > > When determining whether the status of a P-tunnel is Up, a condition > to consider is whether the root of the tunnel, as determined in the > x-PMSI Tunnel attribute, is reachable through unicast routing tables. > GIM>> Thank you for the suggested text, it is much clearer. I might propose a small re-wording to get the following: NEW TEXT: When determining if the status of a P-tunnel is Up, a condition to consider is whether the root of the tunnel, as specified in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. What do you think? > > Section 3.1.2 has a similar concern. > GIM>> I agree and propose the following update: OLD TEXT: A condition to consider a tunnel status as Up can be that the last- hop link of the P-tunnel is Up. NEW TEXT: When determining if the status of a P-tunnel is Up, a condition to consider is whether the last-hop link of the P-tunnel is Up. > > Why is that a SHOULD and not a MUST in Section 3.1.6.1? GIM>> The thinking, as I recall, was that the operator might re-enable P-tunnel tracking, and not deleting the p2mp BFD session(s) might make an implementation to resume tracking faster. Though the gain might be negligent for a single BFD session, but if the same PE is the root for multiple multicast trees, such behavior might be useful. But thinking about that now, we might give the same flexibility and still use MUST. Please review the following update: OLD TEXT: o the P2MP BFD session SHOULD be deleted. NEW TEXT: o the P2MP BFD session MUST be deleted. The session MAY be deleted after some of time. If an implementation uses a timer to delay the cleanup, it MUST allow the configuration of the delay interval, and use a reasonable default value. Same question about > 3.1.6.2, GIM>> I think that it was the same reasoning. Would applying the update as above be helpful? > and the ones in 4.2. GIM>> I think these two SHOULDs could have been MAYs but not MUSTs. In fact, the text that follows uses MAY and then it is used to illustrate what constitutes "cold root standby", "warm root standby, and "hot root standby". The latter is the case when both SHOULD are followed. Do you think that is reasonable? > Or, if they are correctly SHOULDs, you might > consider giving some guidance to the reader about when one might go about > deviating from the advice given, since SHOULD offers a choice. > > I think in Sections 7.2 and 7.3, you don't need "this document" references > for > unassigned things. > GIM>> Thank you, updated per your suggestion.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
