[DMM] Adam Roach's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-dmm-mag-multihoming-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Figure 1 labels the bottom-left most construct "Flow0-4" -- I suspect this
should be "Flow-4."

I see the requests to remove MPTCP from the document, and the rationale seems
sound. If, by some chance, any mention of MPTCP remains in the final version,
please make sure it gets expanded (as an acronym) and cited.

The final paragraph in section 3.2 starts with "Because latency introduced
by..." -- this isn't the reason damage can arise. The problem is the
*variation* in latency. Suggest something like: "Because the variation in
packet latency, also known as jitter, introduced by per-packet scheduling
between access networks can cause..."

Section 4.1, definition of If-ATT -- suggest citing the specific section:
"[RFC5213] section 8.5."

Section 4.1, definition of If-Label -- the value of 0 appears to be reserved?
Ideally, this would prescribe specific behavior for an LMA if they receive an
If-Label of 0.

Section 4.1, definition of BID -- same comment; ideally, this would specify
recipient behavior if set to 0 or 255.

Section 4.3 defines a new response code for LMAs that don't implement this
spec. Existing, already deployed LMAs will necessarily have a different
reaction to receiving these unknown options than sending this response code.
This section should provide guidance for MAGs letting them know what observable
behavior they should expect when sending these options to LMAs unaware of this
extension at all. Additionally, _if_ such observable behavior is sufficient for
the MAG to understand what is happening, I would assert that the new response
code is unnecessary and should be removed.

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - MAG - Mobile Access Gateway (in the title)
 - GRE - Generic Routing Encapsulation
 - LMA - Local Mobility Anchor
 - LTE - Long-Term Evolution
 - MN - Mobile Node
 - BCE - Bonding Channel Entity