Hi Adiyudha,
in a general manner, consider these interfaces as SVI or "tunnels" to connect your router to the service blade.
When loaded with a CGN image, the ServiceInfra interface is used for the management of the card. It's mandatory to have it configured to be able to boot properly the card.
The ServiceApp interfaces are used to send traffic (to be NATed or CGv6ed for instance) to and from your router.
It's necessary to configure an IP address on the serviceApp interface, we configure the router side of the tunnel. All other addresses in the range will be considered to be part of the service card side.
So if you define serviceApp1 10.1.1.1/30, 10.1.1.2 will be answered by the CGN card automatically.
These serviceApps must be part of different VRFs (vrf-lite generally) or at least one in the Global routing table and another in a VRF, to avoid routing loops ----> because you'll have to use static routes to send your i2o traffic into the CGN card and to attract back your o2i traffic to guarantee a symetrical path (important in the case of stateful translation).
So, let's take an example if you define a map pool of 20.1.1.0/24 where the external addresses will be allocated to your translations.
You define serviceApp1 in VRF "Inside" with 1.1.1.1/30.
You define serviceApp2 in VRF "Outside" with 1.1.1.5/30.
You need to configure a default route in the VRF Inside pointing to serviceApp1 (or 1.1.1.2), it will send the traffic to the CGN card to be NATed.
And you need to configure a static route 20.1.1.0/24 to serviceApp2 (or 1.1.1.6) to attract the traffic in the o2i direction.
As you said, the serviceApp addresses are only significant locally to the router and don't need to be advertised to the outside, so they can be RFC1918.
Hope it clarifies a bit (not easy without diagrams to describe such principles).
Cheers,
N.
i2o = input to output
o2i = output to intput
