Thanks for the review, Tommy, inline
On Sun, Feb 26, 2023 at 11:41:50AM -0800, Tommy Pauly via Datatracker wrote:
> Reviewer: Tommy Pauly
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@xxxxxxxx if you reply to or forward this review.
>
> Thanks to the authors for this clear and useful document. Reducing the overhead
> of redundant multicast packets is a good improvement!
>
> The main transport-related comment I have is for section 3.3.1:
> “ Routers MAY support a configurable option for sending PackedAssert messages
> twice in short order (such as 50msec apart), to overcome possible loss, but
> only when the following two conditions are met.”
>
> How will an end point decide to retransmit like that or not? How is loss
> detected?
There is no explicit discovery of PIM packet loss (asser or other). These
are all datagram messages that ideally are subnet multicasted without any
loss. And in large-scale networks under network change events, there will
be thousands of these packets sent back-to-back as bursts, happily overrunning
any reasonable buffer. The only reason why PIM works at scale is because
of LANs typically only using routers from one (or a coordinated set of)
implementation(s) with mutually well tuned burst sending and burst receiving
(been there, done that).
[excurse into my pet topic:
If this sounds ugly to you, please chime in to the message thread i did also
Cc to tsvwg some time ago, where i was trying to convince PIM that we must
require the use of PIM over TCP (rfc6559) for any new work where this can be done.
Alas, i did not get any support not even from TSV folks for that MUST, so i have
to conclude nobody really cares for working CC with PIM. Alas the
assert messages do not lend themselves for PIM over TCP because they need
to be multicasted to as many as 50 routers on a LAN. ]
Enabling this MAY duplication would just be a nerd knob to enable by an operator when
scale is so high that packet losses (during those bursts) occur. I did not want to go any
further than a may because i think this "reliable bursts of datagrams" is
soemthing we have no good IETF standards for.
But: In IGMP and MPLS protocols we do mandate duplication of all new-state
messages for 30 years now. Except that for those protocols (unlike PIM asserts),
there is almost never a big burst that would have to be sent. Hence good
mechanism experience, but little to no scale experience i think. Hence MAY
(and no default) to suggest experimentation but nothing more.
---
Will fix the nits below on next revision of the doc. Thanks for those. Its annoying how
many of those nits still get through every time even with serious efford to avoid
them *sigh*.
Cheers
Toerless
> I did find several nits:
>
> “RP” is mentioned in the introduction before it is defined. It would be useful
> to expand this here. It would also be good to expand “AT” on first use.
>
> Section 3.2 seems to have a formatting issue, with “ If the P)acked flag is 0”.
> Do you mean “ If the (P) flag is 0”? This section also says “If the (P) flag is
> 2”; how can a 1-bit flag have a value of 2?
>
> In section 3.3, “Only the compactness of their encoding” is a sentence
> fragment, not a complete sentence.
>
> In section 3.3.1, this normative requirement is confusingly worded: “
> Implementation SHOULD NOT send only Asserts, but no PackedAsserts under all
> conditions, when all routers on the LAN do support Assert Packing.” Can you
> rephrase?
>
> In the same section, please add a reference when discussing DSCP markings.
>
> In section 4: In the packed form, are the version/flags fields repeated? Do we
> need to mandate normatively that the packed flags are not nested? It’s implied
> but not normatively said.
>
> In section 4.4.1, the field description order doesn’t seem to match the
> structure values in the diagram.
>
>
--
---
tte@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
