Early Review of draft-ietf-rtgwg-dst-src-routing-revive-04
review-ietf-rtgwg-dst-src-routing-revive-04-rtgdir-early-chen-2025-09-22-00

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/ draft-ietf-rtgwg-dst-src-routing-revive/

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.

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

Document: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-dst-src-routing-revive-04
Reviewer: Mach Chen
Review Date: 19 Sept 2025
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

Comments:
1. Given the following reasons, I strongly believe that the intended status of
this document should be Experimental.
 - The document gives the fundamental change to the current destination-based
 architecture, more evaluations and experiments are needed before it can be
 published as standard track RFC. - Interoperability with the large installed
 destination-based routing equipment has not been demonstrated, and it is
 unclear how the two models can coexist during a gradual transition. - There
 has been no significant operational deployment to evaluate the scalability,
 stability, and security properties of destination–source routing in real-world
 environments. - The incremental deployment strategy is uncertain, as existing
 routing protocols and forwarding hardware are designed around
 destination-based lookups - ...

2. It is not clear whether the destination–source routing is designed to
address specific and limited use cases, or it is envisioned as a more general
replacement for the long-standing destination-based routing architecture in the
end. It's better to make the target scope clearer.

3. Although the Abstract notes that destination/source routing,
source/destination routing, SADR, source-specific routing, source-sensitive
routing, S/D routing and D/S routing are all used synonymously, I'd strongly
recommend to select one and use it consistently in document.

4. In section 2.2 it says:
"In direction branch -> HQ the problem is easily solvable by
   having the default route pointing to the Internet link and HQ routes
   pointing to another link.  But destination routing does not provide
   an easy way to achieve traffic separation in direction HQ -> branch
   because destination is the same (branch network)."

I am not sure why the "combination of default route and specific branch/HQ
routes" policy can work for the direction branch->HQ, but cannot work for the
direction HQ->branch? Seems that section 2.2 is not a valid use case.

5. The document allows a network to have the source-destination and
destination-only routing routers, for a source-destination routing router, how
does it know whether it should forward packets using source-destination routing
or destination-only routing? By configuration, or other policies? This is not
clear in the document.

6. RIP/RIPng is mentioned and used as reference in the document, I'd suggest to
remove them since RIP is almost dead protocol in nowadays.

7. In section 6.1, the words of flood/flooding are used through the section,
which are normally used in Link-State protocols, but not in Distance-Vector
protocol, suggest to reword the section and use a proper word, e.g., propagate.

Nits
Suggest to expand the terms when first use, for example, PA, NAT, NPT, DDOS,
RPF, etc.

Best regards,
Mach