I use some peerings types documented in my aut-num object within the registry, to be more exact, what theses peering times mean to me and for the peering partner i tried to explain wyh i use them as is use them. ( i leave out the IXP Type of peering as i had no active peering with an IXP in DN42 currently.)
The following picture hopefully helps to understand the descriptions of the peering types later on:
Peering Type: Standard DN42 Peering
With the Type "Standard DN42 Peering" i would describe the normal peering used by DN42 participants. They accept all prefixes from their peering partner (maybe they do some ROA Filtering and filter on DN42, FreiFunk, ChaosVPN Aggregates, ...) and send them all their prefixes.
Nothing is wrong with that, and thats the peering type i'm started with also. But if you increase your network and every peering sends you ~400-500 prefixes (ipv4 g) and something went wrong (loop, rogue announcement, ...) your network gets this information on every peering. This can set your nodes under heavy load. Also why did you need all prefixes on all 20 peerings on a node? Or on 40 peerings in your network?
Therefore i decided to be more strict on my peerings.
My Standard Peering Types
Peering Type: PEER
Let's look on my normal default peering type. PEER type means the following: i learn all prefixes which originates (route objects in registry) from the peering partner ASN. Vice Versa i will send the peering partner all my originating prefixes, and all prefixes i learned from PEER, CLIENT peerings (and originating routes from my UPSTREAM peerings).
For example, i learn all AS3 originated prefixes (as documented in the registry). I will send AS3 all routes originates from AS5, AS4, AS2 and AS1. I will not send any routes from other ASN's to AS3. So AS3 will not see AS51/AS51 or any other prefix on this peering connection!
So AS3 can connect to AS1,AS2,AS4,AS5 ressources through me, but won't see AS51 ressources.
Peering Type: CLIENT
The second peering type CLIENT, is very similar to the PEER Type, with one change. I will send all my known prefixes to the CLIENT. This means i learn all prefixes which originates (route object in registry) fromt the peering partner ASN. Vice Versa i will send all known prefixes from UPSTREAMs, PEERs, CLIENTs to the peering partner ( with ROA checks of course).
For example, i learn all AS2 originated prefixes (as documented in the registry). I will send AS2 all routes i know, regardless from where i know them (UPSTREAM, PEER, CLIENT, ...). So AS2 should see the full DN42 table (hopefully AS51/52 has some other peerings which i see through my UPSTREAMs).
Normally with this kind of peering AS2 should be able to connect to all DN42, FreiFunk, ChaosVPN ressources i get from any of my peerings. But ASN's connected only to AS2 wouldn't be able to use these connectivity unless they had some second peering which do TRANSIT/UPSTREAM for them.
Peering Type: UPSTREAM
The third used peering type is UPSTREAM. From an upstream peering i will learn all their prefixes regardless if they are originate from their AS or not. Vice Versa i will send the peering partner all my originating prefixes, and all prefixes i learned from PEER, CLIENT peerings (and originating routes from other UPSTREAM peerings).
If my CLIENTs or my own ressources needs to use some ressources from AS10 (which i'm not peering directly with) i will use my upstream ressources to connect to them. Not every node in my network has UPSTREAM peerings, so maybe the routing is through another node of my network to the UPSTREAM peering partner.
Special Peering Types in use
I use two special peering types: PEER w AS-SET and BiDi UPSTREAM. They are only used case by case, but i will try to explain them in short:
Special Peering Type: PEER w AS-SET
On this Peering type i generate an AS-SET in my internal IRRd to allow additional ASN/prefix ressources to be learned & used from the peering partner. For exampple if AS5 has such a peering with me, the AS-SET includes AS5, AS51, AS52 and therefore i learn prefixes originated from all three ASNs through this peering (of course if AS5 sends them to me). The other direction will be the same as PEER type (only PEER, CLIENT, UPSTREAM originated prefixes).
Special Peering Type: BiDi UPSTREAM
Well this is more or less the "Standard DN42 Peering" i described first. I learn all from this peering partner (of course with ROA checking) and send them all i know. I think this peering has also the same problems than the "Standard DN42 Peering" and i will only use this very rarely.
Hope this explain the behaviour of my network a bit more.