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: