[DMM] draft-ietf-dmm-mup-architecture-02 early Rtgdir review

Document: draft-ietf-dmm-mup-architecture
Title: Mobile User Plane Architecture for Distributed Mobility Management
Reviewer: Joel Halpern
Review result: Not Ready

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-dmm-mup-architecture/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

This review is provided with the understanding that the draft is approaching
completion.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-dmm-mup-architecture-02.txt
Reviewer: Joel Halpern
Review Date: 15-Aug-2026
Intended Status: Proposed Standard

Summary:
Choose from this list...

I have significant concerns about this document. It needs more work before
being submitted to the IESG.  I believe most of these issues are matters of
explanatory text and grammar, not issues of technical flaw.  But it is hard to
be certain.  There are also issues of appropriateness of scoping as it seems to
define BGGP procedures.

Comments:

The document describes an alternative architecture for a mobility
infrastructure.  It describes it as being related to the 3GPP architecture, and
attempts to use 3GPP terms appropriately.  However, the document is quite hard
to read and understand.

Major Issues:
    It is unclear to this reviewer if this draft is actu
Give as much context information as possible with your comments (e.g., section
numbers, paragraph counts).ally informational or standards track.  It describes
an architecture.  It describes that there need to be protocol extensions to
support that architecture.  Presumably for reasons of scoping and appropriate
responsibility, this document does not standardize protocol extensions.  So
what is being standardized?  The requirements are stated to be taken from
another document.

    It is also odd, in a document that is not defining protocol extensions, to
    provide example extensions.  It seems to invite readers to treat those as
    extensions to be used, even though they are not formally adopted by this
    document.  This becomes even more confusing when the document proceeds to
    state that it defines a MUP extended community.  There are very specific
    BGP rules limiting how extended communities can be defined, and as far as I
    know it needs to be done by the IDR working group.

    Apparently, the architecture intends to require the use of BGP.  Such a
    requirement is understandable.  But it was not stated before the text
    suddenly introduced reliance on extended communities.  And then in section
    6 introduces further BGP dependence.  I suspect that the assumption is that
    the PE devices correspond to the AS boundary devices, and this is all
    assumed to be used in iBGP.  But I can't find the text that explains that
    before it is relied upon.

    As a reader, I am quite confused as to what constitutes a MUP segment. 
    From some of the diagrams, it seems to be a portion of the network,
    delimited somehow.  On the other hand, there is text that an SRv6 SID can
    correspond to a MUP segment.   An SRv6 SID identifies a node, not a portion
    of the network.  (Yes, this is a general issue with segment routing where
    we often treat the node as if it represents the path portion that
    terminates there.  Within an SR SID list of any type, this can usually be
    understood.  The usage here is not in the context of a SID list, so I am
    unsure what is meant.)  This makes review of the subsequent discussion of
    discovery somewhat more difficult.

Minor Issues:
    In section 3 on architectural principles, there appear to be grammatical
    problems in the core statements of the principles.  This is most easily
    seen in the third principle where the text starts with the apparent
    sentence "The third principle is that transforming session information to
    routing information."  That is neither a sentence nor a principle.

    I found the explanation in section 4 of the difference between a direct
    segment and an interworking segment very hard to parse.  I am not confident
    enough of my understanding to suggest specific new text.  I strongly urge
    that it be revised for English clarity.

    In section 6, section 6.1 states that type 1 information is for carrying
    addresses of nodes to be reached over the access network.  I would then
    expect that type 2 information is for carrying information abut
    destiantions / prefixes reach over the non-access network.  As far as I can
    tell the text does not say that, but leaves the reader guessing as to what
    type 2 information is for.

Nits:



_______________________________________________
dmm mailing list -- [email protected]
To unsubscribe send an email to [email protected]