On Thu, Dec 17, 2020 at 8:57 PM Greg Mirsky <gregimir...@gmail.com> wrote:
> > 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? > Yep, that's better. >> 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. > Looks good. >> 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. > Taking my own run at it; either is fine: o the P2MP BFD session MUST be deleted. The session MAY be deleted after some configurable delay, which should have a reasonable default. > Same question about >> 3.1.6.2, > > GIM>> I think that it was the same reasoning. Would applying the update as > above be helpful? > Sure. > >> 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? > My concern generally is just this: 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. >> > If you feel that your suggestion resolves that concern, I'm happy. -MSK
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
