In brief , there is an E-BGP session between the two ASBR , that advertises the IPV4VPN routes between the two AS.
Before advertiseing the update the ASBR will change the next hop attripute of the ipvpn route to the peer IP address (ie the local interface directly connected to the other ASBR) this is the normal BGP opration.
On Router ASBR2, use the show route receive-protocol command to verify that the router receives and accepts the 18.104.22.168 route and places it in the bgp.l3vpn.0 routing table. user@ASBR2> show route receive-protocol bgp 22.214.171.124 extensive inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) * 1:100:126.96.36.199/32 (1 entry, 1 announced) Accepted Route Distinguisher: 1:100 VPN Label: 299984 Nexthop: 188.8.131.52 AS path: 100 I Communities: target:1:100 rte-type:0.0.0.2:1:0
What I didn't ubderstand why this route would be active when it's received by the other ASBR, since theere is no lsp configured to resolve this nexthop in inet.3 or int.0. There is no rsvp or ldp configured on the link between the 2 ASBRs. How can the next hop be resolved to mpls lsp
Typically IBGP needs to resolve an indirect next-hop (Next hop type: Indirect). For VPN routes the default is to resolve using inet.3 only. This default behavior makes sense as LSPs are by default installed in inet.3 and a LSP is required to transport the VPN (intermediate nodes are only aware of the transport LSP labels and would not know what to do with the VPN label)
But for directly connected EBGP next-hops you don't need this intermediate next-hop resolution step: the next-hop is not indirect.
This is what happens with a typical inter-AS VPN option B. BGP next-hops are directly connected (Next hop type: Router). On the forwarding plane it works because you definitely don't need the LSP : you are sending a MPLS packet whose single label is the L3VPN label adertised by EBGP. In your example it would be 299984 which uniquely identifies the VPN that the prefix belongs to.
I also tested the inter-AS VPN option B with a slightly different scenario where the peering between the two ASBR is not done through the physical IP addresses but through the loopback addresses (realistic scenario if you have for instance two L3 links between the two ASBR and you want to use ECMP, multihop is required). You will notice that this time the L3VPN routes will appear as hidden on the receiving ASBR. Why? Since the BGP next-hop is not directly connected now you need to resolve it (again Next hop type: Indirect). You can then fix that exactly how you would do for "standard" VPNs:
either a LSP between the two ASBR (actually no label required, but it must appear in inet.3, it can even be a static dummy LSP)
or configure routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 which will allow L3VPN routes to be resolved in inet.0 instead of inet.3
Also the statement keep all ist apparently not required. It iseems to be implicit : as soon as you configure a EBGP peering with family inet-vpn, Junos will understand that you are doing inter-AS VPN option B and will keep all the VPN routes in the bgp-l3vpn.0 table (I tested with 12.3R5.7). In a way it is similar to the configuration of a route-reflector: you also don't need to explicitely configure keep all on a route-reflector.