Perhaps I should make some edits for clarity! On Mon, Jan 11, 2021, 16:52 Christian Huitema <[email protected]> wrote:
> I am looking at the text of section 4.2, and I am not sure how I would > implement that. What should be the value of the config rotation bits in CID > created by the server? > Any config includes the corresponding CR bits, and when generating the CID it would use those bits. The confusing part is that, for this algorithm, a usable SID has to be extracted from any CID, hence all the weird stuff about CIDs with undefined configs. Aside from that, it's like PCID: any server-generated CID uses the CR bits in the config, optional length encoding, SID, server-use octets. Should the 6 other bits in the first octet be set to a CID Len or to a > random value? > It depends on the rest of the config, as with the other algorithms. > Issss the timer set when the server ID is first added to the table, or is > the timer reset each time a packet is received with that CID? In the latter > case, is it reset when any packet is received, or only when a "first > initial" packet is received? > When any packet is received with that SID (not CID), the expiration is refreshed. > -- Christian Huitema > On 1/11/2021 4:14 PM, Mikkel Fahnøe Jørgensen wrote: > > Sorry, the following text is out of context - it was a suggestion that I > decided not to persue. > > On 12 Jan 2021, at 01.10, Mikkel Fahnøe Jørgensen <[email protected]> > wrote: > > If the DCID is not understood by the LB, the LB chooses a random target > server but does not store any state. The expectation being that the server > will assign its own DCID on the return path. > > The LB will understand how to route the server assigned DCID. The problem > being that this generally requires shared state - which Low-Config aims to > avoid in exchange of local state. > > >
