Subject: Re: [pim] Adoption of draft-asaeda-mboned-explicit-tracking-02 as a pim wg doc

From: Mike McBride <[email-masked]>
Date: Wed, 28 Sep 2011 19:34:46 -0600

An informational pim-explicit-tracking document seems most appropriate
to me (and, at this point, the only apparent way to have consensus for
adoption in pim).

Please consider adopting the document as informational and speak up either way.

mike

> From: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Date: Mon, Sep 26, 2011 at 6:33 AM
> Subject: Re: [pim] Adoption of draft-asaeda-mboned-explicit-tracking-02
> as a pim wg doc
> To: Hitoshi Asaeda <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
>
> Hitoshi,
>
> > Ok, so you agree on BCP for this draft? If the WG decides it should
> be
> > BCP, I'll follow the decision.
> My personal position has been clear. Of course, it is up to the WG.
>
> 1. Explicit Tracking is a useful feature. There could be a BCP document
> from multimob WG stating (among other things) that Explicit Tracking is
> recommended. This takes care of "why" part.
>
> 2. For the details how it is implemented, an informational document is
> enough. This takes care of "how" part.
>
> Jeffrey
>
> > -----Original Message-----
> > From: Hitoshi Asaeda [mailto:[email-masked]]
> > Sent: Monday, September 26, 2011 2:40 AM
> > To: Jeffrey (Zhaohui) Zhang
> > Cc: [email-masked]
> > Subject: Re: [pim] Adoption of
> > draft-asaeda-mboned-explicit-tracking-02 as a pim wg doc
> >
> > > RFC 3376 merely says in the appendix:
> > >
> > >    o Hosts no longer perform suppression, to simplify
> > implementations
> > >      and permit explicit membership tracking.
> > >
> > > I read it as explicit tracking is not really part of the
> > > protocol/standard, though a vendor could implement on its own w/o
> > > depedning on another router's behavior (as long as suppression is
> no
> > > longer performed, which is alreay required by the protocol).
> >
> > So, what is the spec of your explicit tracking function? When or in
> > what situation does a router turn on that function? When it turns on
> > the function, how does the router change its IGMP/MLD protocol
> > behavior? Describing all the clarifications is useful for the future
> > implementations.
> >
> > >> Moreover, in wireless and mobility environment, the
> > explicit tracking
> > >> would be the necessary function (i.e. SHOULD) to support
> multicast.
> > >> According to this condition, informational is weak assumption.
> > >> I would say BCP is the possibility if proposed standard
> > does not fit
> > >> to its definition, but IMO, PS works well.
> > >
> > > I agree that wireless/mobility environment it is BCP to use
> explicit
> > > tracking, but I think all we need is a BCP document from multimob
> > > WG stating that explicit tracking is required/recommended. How it
> > > is implemented is an internal thing that does not need
> > > standardization. Some parameters in your explicit tracking draft
> > > could be part of the igmp/mld tuning spec.
> >
> > Ok, so you agree on BCP for this draft? If the WG decides it should
> be
> > BCP, I'll follow the decision.
> >
> > BTW, the tuning draft does not require to change the protocol
> > implementations. It aims to become a guideline how IGMP/MLD timer or
> > other values could be tuned in resource sensitive wireless links or
> > mobility env. The explicit tracking function is an implementation
> that
> > changes the protocol behavior, e.g., whether the router sends
> Specific
> > Queries or not in a proper condition. We cannot mix the semantics in
> a
> > single draft.
> >
> > >> BTW, to my knowledge of rfc2026, I haven't thought the
> > >> proposed standard
> > >> should be applicable only for the protocols in which interop issue
> > >> exists, and hence I thought this function could be in the
> > >> standard track.
> > >
> > > Though we used the "interop" wording, the real thing beind it is
> > > that an internal implmentation thing does not need to be
> > > standardized (which we did talk about).
> >
> > I don't know if this is true or not.
> > But again if the WG decides it should be BCP, I'll follow the
> > decision.
> >
> > Regards,
> > --
> > Hitoshi Asaeda
> >
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim