Your first answer is the right one, DLCI (102) define a link from Sending Node to Device A.
Without local significance, then every customer FR PVC will need to have the same DLCI ID value at both endpoints.
Now, assume we are connecting a new customer, what if a DLCI is available on one switch, but the same DLCI is already taken on the 2nd switch by another customer ?
Without local significance, the provider will have to check all the available matching DLCI Pairs on both endpoint switches to connect any new customer, and might not even available matching DLCIs.
With local significance, the provider will just connect the PVC using any free DLCI on the the 1st switch, and any free DLCI on the 2nd switch, even if they do not match.
Note also that the DLCI ID is locally significant to each FR Port on the switch, i.e. DLCI 102 can be used on more than one FR Port on the same switch.
There are a few ways to accomplish a back-to-back frame-relay connection.
A quick search returns the following options:
Your configuration is closer to hybrid switching, however, you're missing a few key elements.
Frame-Relay
Either R1 or R2 will need to have frame-relay switching enabled to act as the frame-relay switch.
R1(config)#frame-relay switching
The newly designated frame switch's Serial0/0 interface needs to be changed to the frame-relay interface type dce in order to provide LMI.
R1(config)#int s0/0
R1(config-if)#frame-relay intf-type dce
Finally you don't need to include the no keepavlive syntax when performing hybrid switching.
EIGRP
Your matching(required) static frame-relay map statements may include the broadcast statement in order for EIGRP to establish a neighbor adjacency.
R1(config)#int s0/0
R1(config-if)# frame-relay map ip 131.1.12.2 100 broadcast
R2(config)#int s0/0
R2(config-if)# frame-relay map ip 131.1.12.1 100 broadcast
IP: s=131.1.12.1 (local), d=224.0.0.10 (Serial0/0), len 60, sending broad/multicast
Serial0/0(o): dlci 100(0x1841), pkt type 0x800(IP), datagramsize 64
Serial0/0(o):Pkt sent on dlci 100(0x1841), pkt type 0x800(IP), datagramsize 64
Without the broadcast statement, EIGRP messages sent to the multicast address 224.0.0.10 will fail to be encapsulated.
IP: s=131.1.12.1 (local), d=224.0.0.10 (Serial0/0), len 60, sending broad/multicast
Serial0/0: broadcast search
Serial0/0:encaps failed on broadcast for link 7(IP)
IP: s=131.1.12.1 (local), d=224.0.0.10 (Serial0/0), len 60, encapsulation failed
Unicast EIGRP
Or, instead of using the broadcast keyword with your static frame-relay map statements to avoid encapsulation failures, you can specify EIGRP unicast neighbors under EIGRP process 100 and your adjacency should form.
R1(config-if)#router eigrp 100
R1(config-router)#neighbor 131.1.12.2 s0/0
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.2 (Serial0/0) is down: Static peer configured
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.2 (Serial0/0) is up: new adjacency
R2(config-if)#router eigrp 100
R2(config-router)#neighbor 131.1.12.1 s0/0
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.1 (Serial0/0) is down: Static peer configured
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.1 (Serial0/0) is up: new adjacency
Best Answer
To be clear: packet switching does not maintain a virtual circuit. There are certain packet switching technologies, or technologies designed for packet switching that do (ie Frame Relay, MPLS, TCP), but as a whole, this isn't how packet switching works. Circuits were required in circuit-switched networks. Since circuits (used in this context) are not relevant anymore, but the technology used that relied on them (the phone system) is, we now have the need to emulate them in packet switched networks, hence "virtual circuits."
In relation to Frame Relay (actually not just Frame Relay - this is relevant in ATM and X.25), SVC and PVC are two different types of virtual circuits. Virtual circuits are paths that are determined through a Frame Relay or ATM/X.25 network (although not many of these exist anymore, aside from some DSL ISPs). PVC is predetermined and configured explicitly (hence "permanent") and SVC is set up "on the fly" in a more dynamic fashion (as-needed basis). IIRC there wasn't much support for SVC's in Frame Relay and from an operational perspective PVC's were more desirable because there were less moving parts (things to troubleshoot/go wrong).
This Wikipedia snippet on virtual circuits in the context of Frame Relay and ATM goes into detail on what "virtual circuit" actually means.
Packet switching can use many paths to send data, but some network layer protocols that run on top of the packet switched network (ie MPLS, ATM, Frame Relay, etc) have a requirement that data is always sent over the same path - the path is the virtual circuit. In MPLS it's called an LSP. In Frame Relay (and ATM) it's called a PVC.