Re: Questions re: draft-ietf-mboned-driad-amt-discovery
Warren Kumari <[email protected]> Thu, 17 Oct 2019 16:58:50 +0200
| Newsgroups | gmane.ietf.mboned |
|---|---|
| Message-ID | <CAHw9_iKD9U7cEzTwmTok-8Dp96i6wpW4R+4P+6oMQkGB_j8+_g@mail.gmail.com> |
On Thu, Oct 17, 2019 at 4:10 PM Holland, Jake <[email protected]> wrote: > > Thanks Warren, > > Responses inline with [JH]. > > > On 2019-10-14, 23:37, "Warren Kumari" <[email protected]> wrote: > ... > > While doing my AD review of draft-ietf-mboned-driad-amt-discovery I > looked at the Shepherds Writeup (thanks Tim) and saw: > "I would suggest that the text in 2.3.1 on applying a Happy Eyeballs > algorithm where there are multiple choices for the relay be expanded; > it is very vague at present. I presume that this may result in > multiple unicast AMT streams coming in to a given gateway, and all but > one of these would be pruned back, but some specifics on that, and how > the preferred stream is retained, would be useful. This also needs to > be set against the proposed active/active failover mode described in > 2.4.3." > > I think it would be really useful if this could be done before I start > IETF LC; I also found this vague, and think that it will get lots of > comments / questions querying LC. > > > [JH] OK, thanks for the feedback (and to Tim). I'll try to come up with > some language to address this. It'll take a little thought on how to > make it less vague without importing the happy eyeballs specs, but > I'm sure there's a happy medium somewhere. > Thank you. Please SHOUT LOUDLY once you've had a chance to do so (and / or poke me), so I don't miss it. > > I also have a minor nit: > ... > There are multiple multicast-enabled networks being discussed here, > and "the multicast-enabled network" is vague as to which one is being > discussed -- I'm not quite sure how to fix it though -- I tried "the > local multicast-enabled", this seems better, but still not great. > > [JH] Thanks for pointing that out. What do you think of just adding > "receiver's"? Like this: Wow, that's simple and easy - thanks. W > > OLD: > 2. The join propagates with RPF through the multicast-enabled > network with PIM [RFC7761] or another multicast routing > mechanism, until the AMT gateway receives a signal to join the > (S,G). > > NEW: > 2. The join propagates with RPF through the receiver's multicast- > enabled network with PIM [RFC7761] or another multicast routing > mechanism, until the AMT gateway receives a signal to join the > (S,G). > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ MBONED mailing list [email protected] https://www.ietf.org/mailman/listinfo/mboned