On Thu, 5 Dec 2013, John MacAuley wrote:
There was a long conversation on this where I presented many options and specifically asked for the requirement that the control plane connectivity minimally follows the data plane to simplify signalling. The answer agreed upon in the meeting was NO, we cannot assume the control plane connectivity follows the data plane. This was the reason for the control plane topology "peersWith" relationship, without which, you cannot determine the correct path for delivery of NSI CS message. This effectively decouples the signalling plane from the data plane. Good or bad this was the agreement.
Yeah. Unfortunately this is/was very much a vacuum decision. When one start to mix in thrust/security and how things actually have work, it gets very odd to not have control and data plane go hand in hand IMHO. We have been very cautius about making firm decisions on how the system should act as a whole, and have been making a lot of low-level decisions instead, but this makes it very difficult to see how the system should actually work.
Prefix matching is limited to one level.
Can you expand on what this specifically means?
Basically when advertising the topology ids, you are not allowed to have stuff like this: nordu.net:topology: nordu.net:topology:whatever But this can also be inferred from the port id -> topology id inferring rule.
Allowing an NSA to manage a Provider (I avoided using Domain Name for clarity) with multiple Networks, and enumerated local identifiers.
Not sure if this is related to the previous question or not.
From reading these two sections it looks like you are proposing a summary routes mechanism with related domain level costs then implementing a chain model for signalling. True?
Sounds right. Not sure what you mean with "summary routes mechanism with related domain level costs". I like to think that the scheme is somewhat similar to OSPF. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet