Subject: [Bier] Fwd: draft-ietf-bier-path-mtu-discovery-03 comments

From: Greg Mirsky <[email-masked]>
Date: Tue, 8 May 2018 13:27:34 -0700

Now with correct BIER WG list
---------- Forwarded message ----------
From: Greg Mirsky <[email-masked]>
Date: Tue, May 8, 2018 at 12:15 PM
Subject: Re: draft-ietf-bier-path-mtu-discovery-03 comments
To: Toerless Eckert <[email-masked]>
Cc: [email-masked], [email-masked]

Hi Toerless,
thank you for the review, your thoughtful comments. Please find my answers,
notes in-line and tagged GIM>>.

Regards,
Greg

On Tue, Apr 3, 2018 at 3:36 PM, Toerless Eckert <[email-masked]> wrote:

> Quite nice. Almost makes me not hate PMTUD ;-)
>
> Would suggest to add two explanatory things
>
> 1) Abstract
>
> Sentence like "PMTUD for BIER as described here is significantly easier
> than PMTUD for IP multicast, because it leverages unique properties of
> BIER"
>
GIM>> How about
OLD TEXT
   This document describes Path Maximum Transmission Unit Discovery
   (PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
NEW TEXT
   This document describes Path Maximum Transmission Unit Discovery
   (PMTUD) in Bit Indexed Explicit Replication (BIER) layer that leverages
   unique properties of the BIER architecture.

>
>
> 2) Add section "comparison with PMTUD for IP multicast"
>
GIM>> I couldn't find any reference to PMTUD for IP multicast neither RFC,
nor an implementation. Without such source comparison, I'm afraid, may look
like speculation. Third paragraph in Section 2 points to some of the
problems that you've detailed. Perhaps we can let the reader to uncover the
challlenges of PMTUD in IP multicast. What do you think?

>
> Summarize the claim from abstract, e.g.:
>
> a) The network/transport stack of sender in IP multicast has usually no
> clear
>    understanding who their receivers are, so it is more difficult to
> figure out when to re-probe.
>
> b) Senders in IP multicast can not target any subset of receivers to probe
> their
>    MTU. In BIER this is at the core of the BIER forwarding mechnism.
>
> c) Midpoints in IP multicast with an MTU issue have even less chance to
> know
>    what subset of receivers is south of the adjacenc with MTU issues (the
> sender
>    could have application layer mechanisms to know all receivers). In BIER
> this
>    knowledge is immediately available from the bitstring of the packet
> causing the issue.
>
> d) IP multicast trees can be arbitrarily large, which together with b) and
> c)
>    has resulted in so many IP Multicast PMTUD that there is no standards
> IP multicast
>    PMTUD discovery mechanism.
>
>    In addition to the solutions to a)..c) that BIER provides, the number
> of receivers
>    for every packet is also limited to the BSL.
>
> Or something similar fixing whatever might be wrong or missing in above.
>
> Cheers
>     Toerless
>