Re: [babel] Adding two babel milestones

Adding "IESG submission of IPv4 via IPv6" as a
milestone is fine by me, because we're about to do that
anyway. I've never found milestones to be useful, so
I'm not sure there's any benefit in doing this as opposed
to just submitting the draft for publication.

I'm supportive of Juliusz making editorial changes before
submitting to the IESG, I'm sure the IESG review will lead
to editorial changes anyway, and so will IETF last call.

Regarding the "WG adoption of a Babel multicast draft"
milestone, I would personally like to see such a draft
written and discussed at a WG meeting before a
milestone is added. That would ensure that we have folks
willing to do the work for this to happen.

I disagree with Donald's statement that "a routing system that
doesn't handle both unicast and multicast seems incomplete",
because I have yet to find a general-purpose use-case for
non-link-local multicast whereas unicast is general-purpose :-)

David

On Tue, May 25, 2021 at 11:25 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

> Hi Juliusz,
>
> On Tue, May 25, 2021 at 11:03 AM Juliusz Chroboczek <jch@irif.fr> wrote:
> >
> > Hi Donald,
> >
> > > So, I plan to add the following two milestones (I believe new
> milestones need
> > > to be OKed by our AD):
> > >
> > >   June 2021   IESG submission of IPv4 via IPv6.
> >
> > Donald, I'd like to expand the introduction to this document before it is
> > submitted to the IESG -- no content changes, just wording.  Is it
> possible
> > to do that without restarting last call?
>
> Probably. The Introduction does not seem to be controversial. I
> suggested a change to the Introduction here
> https://mailarchive.ietf.org/arch/msg/babel/5HEAHOesxnerhhq9rZcy92hjfwI/
> and there were no complaints. You could propose a different change to
> the Introduction as a resolution to my comment. Since all this is
> getting posted to the WG mailing list, if no one speaks up in 7 or 8
> days and there are no technical changes to the protocol, I don't think
> we would need a new WG Last Call.
>
> > >   Sept 2021   WG adoption of a Babel multicast draft.
> >
> > What do you envision?
>
> Multicast is mentioned in the Babel WG Charter as something optional
> to work on. This is just my personal opinion but a routing system that
> doesn't handle both unicast and multicast seems incomplete to me.
>
> > Babeld works with PIM-SM (that's what the
> > "reflect-kernel-metric" option is for), but I'm not seeing a lot of
> > interest.
>
> Is this discussed in any of the Babel RFCs or drafts? Seems like
> something somewhere in the IETF Babel documentation should talk about
> at least a way to do multicast.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
> > I'm not following the DNSSD/mDNS community closely, but I'm
> > under the impression that they're focusing on multicast-to-unicast
> proxies
> > instead of site-local multicast (draft-cheshire-mdnsext-hybrid).
> >
> > There's also Sandy's BIER for Babel work, but I fear it may have been
> > abandoned.
> >
> > > Perhaps the Babel WG meeting at the July IETF meeting (July 26-30)
> > > should focus on multicast.
> >
> > My personal plans are to finish merging HMAC and v4-via-v6 into babeld
> > mainline, and then to get back to working on network-layer mobility:
> >
> >   https://www.irif.fr/~jch/software/sroamd.git
> >
> > -- Juliusz
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>