[Nsi-wg] UvA/TUD topology exchange proposal

[Diederik Vandevenne]

Hi Henrik,

Thank you for explaining your example. I now do understand your policy problem better. To describe your example in more general terms: you have policies that allow restricted transit to domains that are not your direct neighbors (more than one hop away).  I guess this is one of the cases where the policy cannot be exposed only by the topology information itself. However, without going too much into detail, there are other ways to handle these policies.

One idea is to indicate for each SDP in the topology file that transit is allowed, denied or restricted. If the pathfinder has to choose between a domain that allows transit and one that has a restricted transit policy, the pathfinder may prefer the domain that always allows transit. If there are only domains with restricted transit to choose from, you could just let the requesting agent try to see if it works, as Jerry suggested, or the domains can for example link to a policy file which can be used by the pathfinder to choose the best path. The proposal of the UvA also allows to distribute personalized topology files based on the identity of the requesting NSA. But I guess I am going again to deep into the technology and finding solutions ;). The point I want to make is that there are solutions for your (policy) problems that can work with a system that uses NML topology files and (tree based) control / signaling planes that are distinct from the data plane.

I totally agree with what Guy said during the last conference call: We want to do something new. Why bother with NSI if you only want it to be a copy of BGP? As Guy said, NSI can be seen as a form of SDN where the network is a resource that can be controlled by applications and end users (based on a policy of course). The usefulness of NSI would be limited if it would work in the same way as BGP. Also note that if the services offered through NSI and BGP are not the same, the policies may also be very different. The limitations you see now may not even apply. 


Kind regards,

Diederik



SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300

| Diederik Vandevenne | Infrastructure Services  | SURFsara |
| Science Park 140 | 1098 XG | Amsterdam | 
| T 06 4798 8196 | diederik.vandevenne at surfsara.nl | www.surfsara.nl |

On 19 Sep 2014, at 11:24, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> Hi Diederik
> 
> On Thu, 18 Sep 2014, Diederik Vandevenne wrote:
> 
>> Sorry to jump into this discussion. Given the agenda of the upcoming NSI meeting on monday I am very interested in the restrictive policies you have that are not easy to describe or should only work when the control plane and data plane er equal (chain).
> 
> So chaining allows better control of how you connect different networks together. That is, how the data should transit.
> 
>>> The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
>>> 
>>> You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
>> 
>> 
>> If I understand your example well, A is allowed to transit B to reach C, but B is not allowed to send traffic back to A (see diagram below),
> 
> I don't know any cases like that (but I won't say they don't exist).
> 
>> right? If this is correct, I think you should be able to describe this policy in NML with the unidirectional ports and links. Or do you mean B is allowed to transit C, but A is not allowed to transit C through B?
> 
> Moving diagram up:
> 
>> A — B — C — D
> 
> Yes. You can have cases where A is allowed to transit to C, but not D. This is the case for some NRENs that we provide some transit services too, but not our full transit services (due to AUPs about R&E/commercial traffic or simply due to the network having their own peering infrastructure in one region of the world but not another).
> 
>> This would be hard to describe. I think the only way is to make a list of source domains that are allowed to transit. But I do not see how domain C could do this with BGP without the cooperation of domain B. Can you explain?
> 
> You can apply filters in BGP for what you choose to announce further (in fact, this is a core part of BGP to avoid loops). Typically you won't re-announce peering stuff from peering links, but we have customers/peers where this is these cases are not clear cut. Say a customer announces an IP range and some AS-paths to us. We may only announce part of the range and as-paths further down.
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> Software Developer, NORDUnet

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20140919/a678232f/attachment.pgp>