Observation: it seems convenient for buyers to know which paths they can reach by an offer.
The offering AS (the provider) cannot guarantee access to all or any beacons it has received in the past (even if they were received 1 minute before not_before), since the expiration time may happen before the contract starts. What the AS can do is:
List the neighbors attached to itself. Egress interfaces where they will allow traffic sent from the buyer.
Forward beacons received from these interfaces.
List which beacons will be propagated. This mandatory propagation is valid only $T\text{beacon} \cap T\text{contract}$, for each of the beacons
Filter certain beacons due to AS policy. This may include anything expressible by a path policy (filter).
Perform traffic control on any interface. By this I mean some egress interfaces may be more expensive and thus will have a smaller allocation for the buyer. This might be difficult to express, and at least on a first version of the protocol we might omit it. This is of course, the most general approach, as traffic control can also specify 0 bps.
It seems possible that the provider lists the accessible neighbors, beacons that will propagate, and provide samples of beacons it is willing to forward to the buyers.
Detailed conversation here: https://github.com/juagargi/esdx-scion/pull/1/files#r882890787
Observation: it seems convenient for buyers to know which paths they can reach by an offer.
The offering AS (the provider) cannot guarantee access to all or any beacons it has received in the past (even if they were received 1 minute before
not_before), since the expiration time may happen before the contract starts. What the AS can do is:It seems possible that the provider lists the accessible neighbors, beacons that will propagate, and provide samples of beacons it is willing to forward to the buyers.
For the path policies, we will follow the syntax on https://scion.docs.anapaya.net/en/latest/PathPolicy.html