On Thu, 18 Sep 2014, John MacAuley wrote:
In times like these I always ask myself "What would Jerry say?" This has helped me quite a bit since he stopped participating in the daily activities of the NSI-WG. Every time I get too deep into the network technology, I can hear Jerry's voice telling me it is too much detail for what we are trying to achieve in NSI. I take a step back, and try to remove myself from the nitty gritty details of the specific networking technology. Something to think about…
So this seems like an argument to encapsulate the behaviour instead of describing it.
I have been thinking about the policy topic quite a bit, and I think we have policy in a number of places:
1. Within networks as described by Henrik. 2. Within services definitions - policies on the defined services we offer. 3. Within user requests - we talk about path constraints but these are user specified policy to guide the reservation request (and part of the service definitions).
The good thing is if a policy can be enforced it can be described.
Sure, but it doesn't mean that it can be described with whatever is the current fashion in topology description. What BGP did was to throw away complicated routing protocols and simply announce reachabilty (path vectors, which is slighly different from distance vectors) over each link. This gives the network admins full control over what to announce to other networks, and hence completely removes the need to describe policy. If I can tell each of my networks what they can reach through my network, possibly with some preference for multi-homing, they don't need to know anything else. Sure, BGP doesn't capture everything and you need agreements about what can be re-announced, but this is usually not a problem since network don't want to provide transit unless you are handing them money. I am not saying that BGP is the shining light of all routing/pathfinding and we should carbon copy it. But it does represent 40 years of networking. So when someone comes up and presents something completely different, I'd expect a coule of good reasons. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet