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