Re: [babel] Adding two babel milestones

[David Schinazi <[e-mail]>]

On Tue, May 25, 2021 at 9:02 PM Donald Eastlake <[e-mail]> wrote:

> Hi David,
>
> On Tue, May 25, 2021 at 8:24 PM David Schinazi <[e-mail]>
> wrote:
> >
> > 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 think milestones give an idea of what the WG has accomplished or may
> accomplish in the future. They sort of supplement the Charter. But I'm
> willing to admit that the "IESG submission of IPv4 via IPv6" doesn't
> add that much. On the other hand, it's mostly the Chairs doing the
> work to modify/track the set of milestones.
>

To clarify, I don't object to the chairs creating a
"IESG submission of IPv4 via IPv6" milestone.

> 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.
>
> OK.
>
> > 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 don't see why a milestone can't be aspirational.
>

Does the aspiration reflect WG consensus? My understanding
is that we're a very implementation-driven WG, and I'd prefer to
have aspirations reflect what implementers aspire to build.
Alternatively, hearing from someone who runs a Babel network
telling us that they have a need for multicast would also be great.

> 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 :-)
>
> What makes one use "general" and another "special"?
>

I'd say "general-purpose" means there are several applications using
it, whereas "special-purpose" is for a single application.


> What is a "link"? Say you have a network of Babel routers. Some
> communicate by radio where the transmission on one of its radios by a
> router may be received by zero, one, or more other routers. Some
> communicate by wire/Ethernet but some of those connections are bridged
> so those inter-router connections are more stable but can be
> bi-lateral or multilateral. What exactly is a link in this network?
>

My personal definition is: two devices are on the same link if they can
hear each other's Babel Hellos and IHUs.

I tend to think of multicast as being either discovery multicast or
> application multicast. For application multicast, generally you can
> use head end replication and unicast which is less efficient in terms
> of link utilization and generally has higher latency due to multiple
> copies being sent on a link but might be simpler; on the other hand,
> if there are lots of sources and multicast groups, these head ends
> have to all keep track of who to unicast to. For discovery, you can't
> do everything with unicast because, by definition, you want to be able
> to find nodes that you don't know about yet; but you can probably get
> away with unicast + link local multicast for some definition of link.
> So I agree you can find some way to do everything with unicast and
> link local multicast but that doesn't mean it is the best way to do
> everything.
>

In my mind, the best way to perform discovery is to combine unicast
and link-local multicast. That's what we use in DNSSD which is AFAIK
the IETF-recommended way to perform service discovery.

David


Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
> > David
> >
> > On Tue, May 25, 2021 at 11:25 AM Donald Eastlake <[e-mail]>
> wrote:
> >>
> >> Hi Juliusz,
> >>
> >> On Tue, May 25, 2021 at 11:03 AM Juliusz Chroboczek <[e-mail]>
> 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   [phone] (cell)
> >>  2386 Panoramic Circle, Apopka, FL 32703 USA
> >>  [e-mail]
> >>
> >> > 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/babel
>