[Nsi-wg] UvA/TUD topology exchange proposal

[Diederik Vandevenne]

Hi Henrik,

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).

> 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), 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? 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? 

A — B — C — D


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 18 Sep 2014, at 15:48, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> Hi again (sorry for the slow response time)
> 
> On Mon, 8 Sep 2014, Ralph Koning wrote:
> 
>> Hi Henrik,
>> 
>> Thanks for your comments; it seems that some things are left unclear and
>> let me elaborate on this. Naturally, we will improve the text in the
>> next document version. As both Miroslav and me will be present at the
>> Nordunet conference we can further elaborate and clarify the model.
>> 
>> #0  The document is a proposal for a topology exchange
>>   - It is not a requirements document (upcoming/promised by Chin/John)
>>   - It is not a comparison of routing techniques
>> 
>> #1  Topology exchange != routing
>>   We distinguish between 'topology exchange' and 'path calculation'.
> 
> You cannot separate these. The requirements inherently affect what information is published/exhanges between networks/NSA. Similarly the routing algorithm affects how the information gets passed around.
> 
> 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).
> 
> I wish more people would look at BGP. There is a notion in the group, that BGP is somehow bad or restrictive. However, the reason BGP is successfull it because it allows representing the underlying policy of the network AND being able to change up/downstream.  This is completely impossible with the single description-per-network idea of NML (which mainly seems to come out of multi-layer pathfinding research, and if you are just interesting in hardware capabilities that approach is fine). It is not BGP that creates the policy, it just exposes it.
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> Software Developer, NORDUnet
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- 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/20140918/7a442923/attachment.pgp>