Background:
I've skimmed the reference M02@rt37 provided. BTW, what's the exact/specific SM module you have?
Two factoids that caught my attention, the SM module only (?) uses "internal" gig connections (at least 1, maybe 2?) to the (10g?) MGF fabric. Also, the SM module, described in the reference, is a variant of the 3560E (when I saw the QoS references, I wondered, as the QoS architecture seemed to be that of a 3560/3750.)
BTW, my "dated" information, was based on 2800 series ISR, and their Ethernet module options. I assumed (so far, not totally incorrectly [?]) their architectural approach might still apply to 4000 ISRs.
I had used L2 Ethernet modules in the 2800s, but never used one of their L3 Ethernet modules. So, don't know, without researching, exactly what the interface options, if plural, were between a L3 module and the router.
Skimming the SM L2/L3 module reference, I tried to get a better idea of its architecture, as the config example implies much. Unclear whether that's the only way for the router and module to work together, or the "best" way.
Your question: "why do we see some recomendations of using a bridg domain and service instance in order to connect the router to the module"
For starters, as I previously noted, if the module supports L3, for VLAN to VLAN routing, we want to (much) avoid using the router for that.
It appears, from the referenced documentation, the L2/L3 module really may/does much operate as a separate device, from the router, and they are (logically/physically) interconnected via a gig (?) interface.
If such, I would have expected the interconnecting "link" between the router and its module to provide L2 transit, with some form of L3 addresses, for both the router and module (sharing the "link").
Think of it much like a physically separate router and L3 switch, with a connecting link, attached to ports on both the router and the L3 switch.
If that's in fact, what the architecture works like, although you can do what Cisco shows, I'm (currently) baffled why Cisco shows to do it this way. Why?
Because you've defined the module interface as a trunk, but only allowing a single VLAN. So why use a trunk? Perhaps so we can use L2 CoS?
On the router side, since we're connected to a switch trunk, we don't use a subinterface to accept a VLAN tagged frame, instead we "rewrite ingress tag pop 1" which I believe (?) discards the VLAN tag, for ingress.
It doesn't make much sense, unless, perhaps, the bridge interface on the router allows us to use two SM modules, supporting the same VLANs? Or we need a bridge interface because of the way the router and other hardware, such as a SM module, share the MGF?
With what I know so far, I cannot explain, "why" Cisco is doing what they show. I can say, functionally, it should work fine, and perhaps optimally or nearly optimally. (Why "nearly", again the purpose of using tagged frames between the router and module, for a single VLAN while doing L3, unknown to me.)
Lastly, unlike earlier L2 only modules, which "integrated" into the router, sort of making the router a hybrid L3 switch, in the case of SM module, perhaps logically, it remains very much its own device in many respects. At the moment, I don't know if other SVIs, on the module, are directly visible to the router.
What might be ideal, would be someone to add a reply that's used such modules, where they can tell us, how the router and the module "see" each other. Otherwise, much slogging through Cisco documentation.
