proposal: private ISDs

[tzaeschke]

This proposal aims to resolve scaling issues with large numbers of ISD and core ASes. As a side effect it introduces new privacy features, censorship protection, and (maybe) removes the need for inter-ISD peering links.

See PR #4826

[tzaeschke]

Private ISDs

• Author(s): Tilmann Zäschke (+ ideas from others)
• Last updated: 2025-11-07
• Discussion at: proposal: private ISDs #4827
• Status: WIP

Other references:

• Overlapping ISDs Overlapping ISDs #4293
• Nested ISDs (Scion Book 1, Section 3.6): https://scion-architecture.net/pdf/SCION-book.pdf

Abstract

TL;DR This proposal aims to resolve scaling issues with large numbers of ISD and core ASes. As a side effect it introduces new privacy features, such as hiding ASes and links, and improved censorship protection by using inter-ISD peering links as normal first class links in segments.

The current ISD design combines several features:

1. An ISD has a globally unique ID.
2. An ISD has a core AS that is part of the global network of core routers.
3. An ISD has its own independent TRC
4. An ISD has its own beaconing and independent routing

Features (1.) and (2.) cause several issues:

• The number of ISDs is limited to 65000 (spec: 4000). A change would require modification of the dataplane, i.e. the SCION header.
• Every ISD has at least one CORE AS. A global network with 65000 core ASes would break down. We should aim to have at most a few 1000 CORE ASes.
• Many entities may want to control their own ISD but do not want to participate in the global core routing network because they are not interested in transit traffic and need ways to avoid it.

However, it seems like that many entities that are interested in setting up an ISD are only interested in the features (3.) and (4.).

This proposal introduces Private ISDs (or User-/Anonymous ISDs, TBD). Private ISDs (P-ISDs) provide the features 3. and 4. (independent TRC and routing) without requiring an features 1. or 2. (ISD number or a CORE AS).

Background

Terminology

• P-ISD - Private ISD
• P-CORE - The core router(s) of a P-ISD. P-ISDs provide TRCs and local beaconing but (usually) do not participate in the normal ISDs' core routing.
• BR - Border router
• CS - Control service / path service
• Private AS - A Private AS is part of an P-ISD but not visible from outside their P-ISD. Private ASes cannot have a parent AS outside the P-ISD. Every P-ISD must have at least one non-private (public) AS in order to have a connection to the outside.
• Private Links - A Private Link is a link that is only visible inside a P-ISD.

Proposal

Building a P-ISD

1. We select a group of ASes to form an P-ISD. These ASes can be from different ISDs, but they must be non-separated, meaning that they must form a single contiguous network where every AS can reach every other AS without leaving the network. A P-ISD may use the same interfaces/links between ASes that are already in used by the public ISD or by other P-ISD. It may also use interfaces/links that are not otherwise available.

2. We chose one or more of the selected ASes to be P-COREs. Like normal ISD cores, these P-COREs provide TRC and beaconing for all ASes in the P-ISD. However, unlike normal ISD cores, P-COREs do not have external "core" links to any other (P-)ISDs.

3. Pick an (P-)ISD number. For now, we can use any ISD number from the [private range (16-63)]
   (https://github.com/scionproto/scion/wiki/ISD-and-AS-numbering). In case of nested P-ISDs, we need to ensure that no AS participates in P-ISDs that use the same ISD number.

The resulting P-ISD is built mostly like a normal ISD: It has a TRC, performs beaconing, has at least one CORE AS, ASes have child/parent/peer relationships. However, there are some differences:

• P-CORE ASes to not perform beaconing outside the P-ISD.
• ASes keep their P-ISD number from the surrounding ISD.
• ASes in an P-ISD can have different ISD numbers (from their respective ISDs.
• P-ISDs are not addressable or even visible from the outside, they don't have an external ISD number.

Note: An P-ISD can contain ASes (including P-COREs) and links that are not visible outside of the P-ISD. These are called "private", see also Private Links and Private ASes.

Note: In all diagrams, ASes have only their public ISD number specified. The P-ISD numbers are not shown but there is one P-ISD identifier in each P-ISD (dashed oval shapes).

Example: Simple P-ISD

Figure 1: The diagram shows a simple P-ISD that consists of 4 ASes (1-20, 1-21, 1-30, 1-31).
Two of these, 1-20 and 1-30, act as cores (P-COREs) for the P-ISD, which means they
provide a TRC and perform beaconing for inside the P-ISD.

Example: An P-ISD spread over two ISDs

Figure 2: A P-ISD that has ASes in multiple ISDs.

If an AS in an P-ISD requests a segment that cannot be resolved locally, it will forward the request to a CORE AS, but which CORE AS?
For building a path to another P-ISD-AS, we should only ask the local P-CORE.
For paths to outside the P-ISD we should only ask the surrounding ISD's core.

Example: An P-ISD spread over two ISDs with two P-COREs

Figure 3: The diagram shows an P-ISD that has ASes in multiple ISDs, with multiple P-COREs spread over different ISDs.

Beaconing

The P-CORE performs beaconing just like a normal core AS. However, PCBs from an P-CORE are signed/extend with the TRC
of the originating P-CORE instead of the normal ISD core.

Path Service

When a CS receives a segment request, it should try to determine whether the destination is inside a known P-ISD. If it is, the CS should contact the P-CORE of the respective P-ISD, otherwise it should contact the ISD's core ASes. By default, the CS should return segments for only one (P-)ISD. In the case of nested P-ISDs, it should return segments for the "innermost" P-ISD.
"Innermost" may be ambiguous in case of overlapping P-ISDs, so a preference hierarchy must be configured in the CS.

This requires an API change in the CS because we need the source and destination ASes to make that decision.

In addition it would be useful to have an request argument where the endhost can specify their preference regarding from which (P-ISD) the returned segments should be:

• No preference specified (default): CS delivers segments from best fitting (P-)ISD (there could be several).
• Preference list of (P-)ISDs: CS delivers segments form all listed (P-)ISDs.
• Preference "ALL": CS delivers segments from all known (P-)ISDs.

See also Nested P-ISDs and Hierarchies.

Endhost: Sending Traffic

Endhosts can, but don´t need to, know their AS's P-ISD. They can get information about P-ISDs from the topofile, control service or from an extended version of the new endhost API service.

When requesting segments, an endhost may specify specific P-ISDs for which it requires segments. If no P-ISD is given, the path server should return any segments it deems fitting.

When constructing a path, an endhost must take care to use segments that are all either from the same P-ISD or all from public ISDs. This rule ensures that P-ISDs traffic remains private.

When constructing a packet, the endhost needs to put the correct (P-)ISD number into the SCION address header, otherwise routing will fail because the BRs will attempt hop field verification with the wrong certificate.

This constitutes a semantic change to the SCION address header, but not a structural change. This change is fully backwards compatible.

Border Routers

For independence of a potentially compromised public ISD, an AS has separate
forwarding keys for each (P-)ISD.
For any incoming data packets, border routers need to look at the P-ISD in
the SCION address header to identify which forwarding key should be used
for authenticating the hopfields.

DRKey, EPIC, ...

Using the P-ISD's TRC, an AS can derive DRKeys which can, for example, be used for EPIC. To verify incoming packets with EPIC, endhosts can get the P-ISD identifier from the SCION address header to identify which DRKey to use for authentication (i.e. the DRKey derived from the public ISD/TRC or from any of the P-ISD's TRCs).

Nested P-ISDs and Hierarchies

P-ISDs can be nested or overlap arbitrarily. However, if an AS wishes to participate in multiple P-ISDs, all P-ISDs must have different identifiers. Also, every AS must specify a preference list for routing, if the source and destination AS have multiple P-ISDs in common, it must be clear from which P-ISD (or ISD) the segments should used.

Figure 4: The diagram shows one large P-ISD with two smaller P-ISDs nested inside it.
In this example the smaller ones participate only in the large one. This need not be the case, the P-ISDs can overlap arbitrarily and partially as desired.

In some scenarios it may be useful if an AS can act as P-CORE for multiple P-ISDs.
For example an ISP could offer to set up P-ISDs as a service for customers,
it's own AS would then act as P-CORE for each P-ISD.
This should work but is limited by two aspects:

• (P-)ISD numbers are limited to 64bit. Even if we use the reserved ISD numbers
  the range would be limited to 60000 or so. This can be circumvented by the ISP
  by setting up multiple ASes, then each AS can serve up to 60000 P-ISDs.
• If the P-ISDs of an ISP include ASes of other ISPs, the P-ISD number may
  conflict with (be the same as) P-ISD numbers used by the remote ISP.
  If an ISP participates in many P-ISDs, it may be necessary to maintain
  additional ASes that allow choosing P-ISDs number that are not already used.

Private Links and Private ASes

P-ISDs allow to hide links and ASes from the rest of the ISD. These are called "private links" and "private ASes". They are visible only to other ASes that participate in the local P-ISD.

Hiding these is achieved by simply excluding them from any PCBs that come from outside the P-ISD. Every private AS needs an AS number. It is recommended, but not necessary, that these numbers are globally unique. Global uniqueness ensures that
the ASes can join a common P-ISD in future without problems.

To hide its existence from the local ISD, a private AS can use the ISD code of a different ISD. There could even be a dedicated ISD code for private ASes.

Figure 5: In this example, only the ASes 1-120, 1-130 and 1-131 and the link between 1-130 and 1-131 are visible from the outside.

Rationale

Advantages and Disadvantages

Advantages

• P-ISDs do not need a globally unique identifier (saves space in the 16bit ISD number space)

• P-ISDs do not (usually) participate in the global network of CORE-AS.

  • That improves scalability: people can have a (P-)ISD without impacting scalability
  • P-ISDs do not need to worry about transit traffic.

• P-ISDs provide isolation + independence of TRC and routing

• P-ISDs can cross ISD boundaries as long as there are links. They can make peering links more powerful by using them as normal links and thus using several of them in a normal segment..

• Privacy: An P-ISD can contain any number of ASes and links that are not visible outside the P-ISD (private ASes). A P-ISD itself is not detectable from the outside.

• P-ISDs can be nested and overlapping.

• An AS can join an P-ISD without having to worry about a 2nd AS identifier. The normal AS number of an AS remains valid and the only way to address the AS.

• P-ISDs can even be hidden from individual endhosts in ASes that participate in the P-ISD.
  Either the path server can choose not to give P-ISD segments to the endhost, or the path server itself could be hidden from some endhosts such that the endhost would contact a different path server that serves only non-P-ISD segments.

• Similar to hiding P-ISDs from specific endhosts in ASes of the P-ISD, we can also hide the P-ISDs from child ASes of P-ISD-ASes.

Disadvantages

• Border routers need more state and compute. They need to know all ASes in all P-ISDs in which the local AS participates.

Alternative: Avoid using ISD numbers altogether

Instead of using P-ISD-IDs from the private range (16-64), we could avoid using any IDs altogether.

P-ISD need to form a strict hierarchy, that means for nested P-ISDs, any inner P-ISD is fully enclosed in exactly one parent P-ISD.
In such a hierarchy, for any given two ASes (source + destination), we can find exactly one P-ISD that is the "innermost" (smallest) P-ISD that contains both ASes.
By default, path services always return segments that lie in this innermost P-ISD.

This way, the two source and destination ASes determine P-ISD whose TRC was used to create the segments and that can be used to authenticate them.
This means border routers can determine the correct certificate from the AS numbers alone, clients do nod need to put P-ISD numbers into the address header. In effect, we do not need P-ISD number at all.

Border routers may use an algorithm as follows:

For every AS, they have a list that represents the AS's P-ISD hierarchy, the first entry is the outermost P-ISD and the last entry is the innermost P-ISD. At each level, we store a reference to the AS's TRC certificate for that P-ISD. When a border router receives a packet, it looks at the first and last AS in the path header. For both ASes it looks up the hierarchy list.

• If at least one of the ASes does not have a list (meaning it is not in any P-ISD known to the BR) then we use the normal ISD's certificate.
• If they both have a list, then we walk through both lists until they differ. This gives us the deepest common P-ISD and the associated certificate.

Advantages of avoiding P-ISD-IDs:

• (Almost) no need to modify endhost libraries.

  • The SCION address header simply contains the public ISD number for SCR/DST
  • Libraries and daemons can request segments without knowing the P-ISD-ID.
  • Endhosts do not need to deal with local AS's ISD number being different from the ISD number use in an UP/DOWN path (path stitching).
  • (Almost): We still need to change the segment request API such that it returns UP and CORE and DOWN segments in one query. Endhosts need to be adapted to that

• Any AS has exactly one ISD number (and no P-ISD number). This may avoid some complexity in control services and in managing ASes.

• No need to ensure that the P-ISD numbers differ in an P-ISD hierarchy.

Disadvantages:

• P-ISDs must form a strict hierarchy.
• Added complexity in BRs and endhosts for determining the correct certificate for authenticating path segments.

Compatibility

There are no conflicts with existing stuff.

The SCION address header needs a semantic change: the SRC/DST ISD number may now be a P-ISD number.
This constitutes a semantic change to the SCION address header, but not a structural change. This change is fully backwards compatible.

All other changes are additions to current features and APIs.

The only constraint is that in any AS, CS and BR must be updated before endhosts are updated, otherwise the segment request API does not work.

It may be a useful extension (separate from this proposal) to add an API version identifier to the CS API so that a client knows which requests are available an which requests will fail.

Naming

The current preferred name is "private" ISD. The name hints at the following features:

• Privacy. The P-ISD is not visible to the outside. What happens in the P-ISD stays in the P-ISD.
• Autonomy. Everyone (who controls one or more ASes) can set it up.

However:

• The term "private ISD" is already in use and refers to ISDs that are physically separate from the production network. This is hopefully not a problem, these ISDs could be turned into P-ISDs, or otherwise we called "separate" ISDs.

One alternative considered was User-ISD (indicating that it is user defined). However, this does not emphasize the privacy aspect.

Another alternative is "Nested ISDs". This is accurate and has the advantage that the naming doesn't conflict with other terminology. Unfortunately, it doesn't really convey the privacy/isolation aspect.
Maybe it is still a better choice than "Private ISD"?

Implementation

1. Control service administration:

   • Mechanism to register ASes and their links and to communicate this to other ASes in the local P-ISD.

   • API for endhosts to learn about all (P-)ISDs that the local AS is part of.

2. Control service API

   • Provide API to allow end-to-end segment requests. The request contains the start AS, the destination AS and an (P-)ISD preference argument.
     The request returns UP+CORE+DOWN segments in one request.
     Stitching (creating) is not necessary, that may still be done on the endhost.
     The (P-)ISD preference argument has three options:

     • "Not set" (or "default"). The CS should return segments from whatever (P-)ISD it thinks is best (configurable by the CS admin)
     • "All" (or "*"). This should return segments from all (P-)ISDs that the CS is willing to share.
     • A list of (P-)ISDs. The CS should return segments only for (P-)ISDs in the list.

     In any case, the CS is free to ignore the preferred (P-)ISD and deliver segments only for some (P-)ISDs (configuration option on the CS).

   • (Optional): Add an request to the API that return the API version. E.g., version "1" would be the version as of Summer 2025,
     version "2" adds a request API for segment requests as described above. This would simplify migration, endhost libraries can find out whether the local AS supports the new segment request API without resorting to
     trial and error.

3. Border routers

   • They need to obtain and handle certificates from the local P-ISDs.

4. Endhost libraries

   • Libraries and daemons need to be adapted to use the new CS API for requesting segments.
   • Libraries need to ensure that they put the respective P-ISDs into the SCION header of each packet.
   • Path policies may need to be extended to allow specifying (P-)ISD preference.

[tzaeschke]

@oncilla @lukedirtwalker @romshark @katyatitkova
A question for the current/future maintainers of the SCION ISD registry:
We are currently registering many ISD that may not need an ISD number after this proposal is implemented (e.g., SCIERA or the private healthcare, financial or energy networks). Considering that these registration may be unnecessary or may even have to be rolled back, do you see any urgency in prototyping and then implementing this proposal?

If there is urgency, this should be implemented by a dedicated developer.
If there is no urgency, then there is the option of a Master thesis that results in a prototype, but as Master theses go, this will take a minimum of six months and the result may not really be useful. This approach could easily take a year before we have a good PR to merge.

What do you say?

[katyatitkova]

Both Roman and I are fully booked until the end of this year, and, in my opinion, this feature isn't urgent enough to deprioritize any of our current tasks. So if it's done as a Master thesis, it probably won't be finished much later than if either of us implemented it ourselves. So I don't see any harm making it a thesis topic.

[shitz]

Given that the order of magnitude of ISD registrations is at most in the 10's and the available number of ISDs is in the 1000's (even 10000's when we lift the restriction) I don't see a big issue when some ISDs exists that might have been private ones.

[tzaeschke]

@katyatitkova @shitz Thanks for your input. We will try to find a Master student to implement a prototype.

[romshark]

Next TC (relative to TC on Sep 17) we want everybody more or less to be in sync and approach acceptance.

[lukedirtwalker]

A few questions below:

When constructing a packet, the endhost needs to put the correct (P-)ISD number into the SCION address header, otherwise routing will fail because the BRs will attempt hop field verification with the wrong certificate.

@tzaeschke I don't follow here. Isn't that the verification key given by the interface the router receives traffic on? I.e. the router listens on a specific addr:port and this is exactly for one interface in one ISD-AS.
Or would in you proposal links be shared, i.e. 10.0.0.1:42421 could be used for interface 1 in public ISD 1-ff00:0:110 and interface 2 in private ISD 16?

Border routers need to look at the P-ISD in the SCION address header to identify which TRC should be used for authenticating the segments.

Border routers usually don't consider the TRC, only the forwarding key.

Endhost: Path Verification
To verify incoming paths, similar to border routers, endhosts can get the P-ISD identifier from the SCION address header.

Here I'm also not sure what this is about?

[shitz]

Hi @tzaeschke. Thanks for the write-up. Unfortunately, I have some problem understanding how the system would work and thus I cannot (yet) give any meaningful input. Below are some questions I had when reading the proposal. Maybe they could serve as a guidance where things would need to be further clarified.

When constructing a path, an endhost must take care to use segments that are all either from the same P-ISD or all from public ISDs. This rule ensures that P-ISDs traffic remains private.

How does the endhost know which P-ISD its local AS is part of?

Relatedly, how can the path service find out whether the destination is in a known P-ISD? The SCION AS number seems to be the enclosing public ISD number. In the proposal, there is only this: “This requires an API change in the CS because we need the source and destination ASes to make that decision.” Is this somehow manually configured? How would that scale?

When constructing a packet, the endhost needs to put the correct (P-)ISD number into the SCION address header, otherwise routing will fail because the BRs will attempt hop field verification with the wrong certificate.

I assume “wrong certificate” actually means “wrong forwarding key”. The BR doesn't do any signature verification.

Border routers need to look at the P-ISD in the SCION address header to identify which TRC should be used for authenticating the segments.

This I don’t understand. By BR I assume that you mean control service. What does this refer to? beaconing? path segment lookup? Why would the SCION address header matter? Why wouldn't this information not be included in the beaconing or path segment control plane messages?

P-ISDs can be nested or overlap arbitrarily. However, if an AS wishes to participate in multiple [P-ISDs], all ASes must have different identifiers

I guess I just don't get how a P-ISD and an AS within a P-ISD is identified. From the diagrams, I understand that the SCION AS identifier uses the ISD number of the enclosing public ISD. Is then a P-ISD just "implicitly defined" as a list of ISD-AS numbers that are part of the P-ISD? Where do you need to have this information and how does this scale?

TODO open question: Disallow one AS being CORE for multiple (P-)ISDs?*
This should be possible, but it is not clear how useful that is and it may add quite a bit of complexity to CS implementations.

This would be extremely useful. You seem to think about the research and education world where there is basically a separate connectivity infrastructure (through NRENs) than for the rest of the world. For a company that would like to have their own P-ISD they would most likely rely on existing network operators to form the core of the P-ISD. That means those network operators would be naturally part of many P-ISDs and thus I would think that this requirement is a must have. Obviously, this can be achieved with various means, including having different ISD-AS numbers, but since I fundamentally don't understand how the P-ISD numbering works, I cannot judge any of the possible solutions.

[tzaeschke]

Thanks for all your feedback!

Apologies, my terminology was a bit vague (especially TRC vs forwarding key etc).

Here ares some answers:

@lukedirtwalker

I don't follow here. Isn't that the verification key given by the interface the router receives traffic on? I.e. the router listens on a
specific addr:port and this is exactly for one interface in one ISD-AS.
Or would in you proposal links be shared, i.e. 10.0.0.1:42421 could be used for interface 1 in public ISD 1-ff00:0:110 and
interface 2 in private ISD 16?

Any interface/link may be used by all associated P-ISDs as well as the normal public ISD. The (P-ISD) number in the packet is required to know which forwarding key to use for verification.

Border routers usually don't consider the TRC, only the forwarding key.

You are absolutely right. I meant to say "forwarding key" instead of "TRC". Text will be updated.

Endhost: Path Verification
To verify incoming paths, similar to border routers, endhosts can get the P-ISD identifier from the SCION address header.

Here I'm also not sure what this is about?

This is about using EPIC and DRKeys that are derived from the TRC of the P-ISD. The text is very unclear and I will update it to clarify this.

---

@shitz

How does the endhost know which P-ISD its local AS is part of?

This information will be provided by the topology file, or the control server (or an extended version of the new endhost API), see Section Implementation, part 1.
However, endhosts do not need to know to which P-ISDs they belong. They can simply request segments, stitch them together and use them.
They only need to be careful to only stitch segments that have compatible (=identical) (P-)ISD numbers, and they must insert that number into the SCION packet header.
The path server determines which segments an endhost will see.

Relatedly, how can the path service find out whether the destination is in a known P-ISD? The SCION AS number seems to be the
enclosing public ISD number. In the proposal, there is only this: “This requires an API change in the CS because we need the source and destination ASes to make that decision.” Is this somehow manually configured? How would that scale?

See Implementation Section part 2.
This is exactly what the new endhost API proposes, when requesting segments, an endhost provides the start-AS and end-AS of the required route. The path server can check whether there is a P-ISDs that contains both AS numbers (we assume AS numbers are globally unique, even without ISD prefix). The server needs to maintain a list of all ASes for every P-ISD in which it participates.
I believe this should scale well, with the caveat the P-ISDs number are 64bit, so an AS can participate in at most 60000 P-ISDs or so. In practice it will be a lot less unless the AS determines the P-ISD numbers and can thus avoid conflicts in P-ISDs in which it wants to participate.

When constructing a packet, the endhost needs to put the correct (P-)ISD number into the SCION address header, otherwise routing will fail because the BRs will attempt hop field verification with the wrong certificate.

I assume “wrong certificate” actually means “wrong forwarding key”. The BR doesn't do any signature verification.

Correct. Text will be fixed.

Border routers need to look at the P-ISD in the SCION address header to identify which TRC should be used for authenticating the segments.

This I don’t understand. By BR I assume that you mean control service. What does this refer to? beaconing? path segment lookup? Why would the SCION address header matter? Why wouldn't this information not be included in the beaconing or path segment control plane messages?

I mean border routers. Border routers will have one forwarding key for each (P-)ISD in which they participate. The border routers
needs to look at the (P-)ISD number in the SCION header to identify which forwarding key to use for hopfield verification.
I will update the text to clarify that.

P-ISDs can be nested or overlap arbitrarily. However, if an AS wishes to participate in multiple [P-ISDs], all ASes must have different identifiers

I guess I just don't get how a P-ISD and an AS within a P-ISD is identified. From the diagrams, I understand that the SCION AS identifier uses the ISD number of the enclosing public ISD. Is then a P-ISD just "implicitly defined" as a list of ISD-AS numbers that are part of the P-ISD? Where do you need to have this information and how does this scale?

I tried to explain that in "Building a P-ISD", part 3. Every P-ISD has a specific number. These number do not need to be globally unique, however, an AS cannot participate in two P-ISDs that happen to have the same number.
Initially, a number of ASes must decide to form a P-ISD and pick a number. How P-ISD membership is handled and communicated is not clear yet, we are looking into that.
Every path server / control server needs to have a list of all ASes for each P-ISD in which it participates. I assume this scales well enough unless we have we get P-ISDs with millions of ASes. Also, the P-ISD number are limited to 64bit, so an AS can participate in at most 60000 P-ISDs.

I can see how the diagrams are misleading. I will try to come up with a better diagram, but no promises.

TODO open question: Disallow one AS being CORE for multiple (P-)ISDs?*
This should be possible, but it is not clear how useful that is and it may add quite a bit of complexity to CS implementations.

This would be extremely useful. You seem to think about the research and education world where there is basically a separate connectivity infrastructure (through NRENs) than for the rest of the world. For a company that would like to have their own P-ISD they would most likely rely on existing network operators to form the core of the P-ISD. That means those network operators would be naturally part of many P-ISDs and thus I would think that this requirement is a must have. Obviously, this can be achieved with various means, including having different ISD-AS numbers, but since I fundamentally don't understand how the P-ISD numbering works, I cannot judge any of the possible solutions.

You are right, I was definitely wearing my SCIERA glasses :).
I assume the proposal would scale well for any AS that participates in 100 or maybe a few 1000 P-ISDs. Beyond that it may get problematic, the ISP would have to maintain multiple ASes.
We will definitely look into an AS being CORE in multiple P-ISDs, I don't see a real problem at the moment.