Attached is a picture (and source) that I've just shown at the NML group. It simply shows a few networks, the representation and delegation (virtualisation) of the network. Feel free to use it to show a few of the issues that are associated with control, topology description, topology aggregation, and delegation. Regards, Freek
Hello Freek: A very nice picture indeed. Indeed lightpath capable domains interconnect among themselves, with dedicated lambdas and/or fibers. What I am missing from this picture is the notion of a GOLE (GLIF Open Lightpath Exchange), an important and growing element in today's global lightpath infrastructure. A GOLE is a typical point on the earth, and hence in the infrastructure, at which lightpath capable domains flock together, and stitch end-to-end lightpath's sections head-to-tail. How could this picture be updated showing a GOLE? Best regards, __ Erik-Jan. On 06/22/2010 06:00 PM, Freek Dijkstra wrote:
Attached is a picture (and source) that I've just shown at the NML group. It simply shows a few networks, the representation and delegation (virtualisation) of the network.
Feel free to use it to show a few of the issues that are associated with control, topology description, topology aggregation, and delegation.
Regards, Freek
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Erik-Jan Bos wrote:
A very nice picture indeed. Indeed lightpath capable domains interconnect among themselves, with dedicated lambdas and/or fibers. What I am missing from this picture is the notion of a GOLE (GLIF Open Lightpath Exchange)
An optical exchange (aka GOLE) in this context is simply a topology. Unlike internet exchanges (which have no layer 3 equipment), optical exchanges do have to be exposed for path finding and monitoring. (They need to describe and announce their switching functionality.) The only distinction between a GOLE and an other domain is that a GOLE is it's policy: a GOLE is "open" and will thus not define a policy on its own (it may enforce the policy of connected domains, though). Since this picture does not iterate on the policies and policy enforcement, it is not necessary to distinguish between the topology of a GOLE and the topology of any other domain. Regards, Freek
Hello Freek and Erik-Jan, Freek Dijkstra wrote:
The only distinction between a GOLE and an other domain is that a GOLE is it's policy: a GOLE is "open" and will thus not define a policy on its own (it may enforce the policy of connected domains, though).
But if 'policy' is an attribute of a domain, then that is even no difference (at least looking at the abstract level). Correct? All the best, Victor
I think another key difference is that a GOLE has a high concentration of cross-border fibers which includes those that interconnects to other GOLEs. In my opinion distinguishing a GOLE from a domain is useful for path computation. Also, we rarely find termination (compute, instrument, etc. ) points within GOLEs. Therefore, their function is to primarily interconnect to other domains and GOLEs. Thanks, Gigi Victor Reijs (work) wrote:
Hello Freek and Erik-Jan,
Freek Dijkstra wrote:
The only distinction between a GOLE and an other domain is that a GOLE is it's policy: a GOLE is "open" and will thus not define a policy on its own (it may enforce the policy of connected domains, though).
But if 'policy' is an attribute of a domain, then that is even no difference (at least looking at the abstract level). Correct?
All the best,
Victor _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
But Gigi, perhaps I see this all as attributes for a domain (although it is perhaps more about the scope of number of interconnectivity in that domain, but I see HEAnet (the Irish NREN) also also only as connecting a lot of domains (of our clients and some international ones) and not really end-systems). For me a GOLE is just a domain (with certain attributes and values). All the best, Victor Gigi Karmous-Edwards wrote:
I think another key difference is that a GOLE has a high concentration of cross-border fibers which includes those that interconnects to other GOLEs. In my opinion distinguishing a GOLE from a domain is useful for path computation. Also, we rarely find termination (compute, instrument, etc. ) points within GOLEs. Therefore, their function is to primarily interconnect to other domains and GOLEs.
Thanks, Gigi
Victor Reijs (work) wrote:
Hello Freek and Erik-Jan,
Freek Dijkstra wrote:
The only distinction between a GOLE and an other domain is that a GOLE is it's policy: a GOLE is "open" and will thus not define a policy on its own (it may enforce the policy of connected domains, though).
But if 'policy' is an attribute of a domain, then that is even no difference (at least looking at the abstract level). Correct?
All the best,
Victor _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario... I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges. thanks, Gigi Victor Reijs (work) wrote:
But Gigi, perhaps I see this all as attributes for a domain (although it is perhaps more about the scope of number of interconnectivity in that domain, but I see HEAnet (the Irish NREN) also also only as connecting a lot of domains (of our clients and some international ones) and not really end-systems).
For me a GOLE is just a domain (with certain attributes and values).
All the best,
Victor
Gigi Karmous-Edwards wrote:
I think another key difference is that a GOLE has a high concentration of cross-border fibers which includes those that interconnects to other GOLEs. In my opinion distinguishing a GOLE from a domain is useful for path computation. Also, we rarely find termination (compute, instrument, etc. ) points within GOLEs. Therefore, their function is to primarily interconnect to other domains and GOLEs.
Thanks, Gigi
Victor Reijs (work) wrote:
Hello Freek and Erik-Jan,
Freek Dijkstra wrote:
The only distinction between a GOLE and an other domain is that a GOLE is it's policy: a GOLE is "open" and will thus not define a policy on its own (it may enforce the policy of connected domains, though).
But if 'policy' is an attribute of a domain, then that is even no difference (at least looking at the abstract level). Correct?
All the best,
Victor _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hello Gigi, Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc. All the best, Victor -- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
There are different ways to look at GOLE's or as the initial name was "Open Exchanges". As many of you remember the first mention of this term that I heard in a discussion between Tom DeFanti and Kees Neggers at the Pittsburgh SC prompted me to think about what they meant with the term "Open". That resulted in a study by Freek Dijkstra an Leon Gommans and some others that resulted in an article dwelling into the notion of exchanges, ownership types and policy. See below for one of the articles and talks about this subject. What does this mean in my opinion: - technically, device wise, there is no difference between domains and goles. If you come from a far planet and you would look at the switches cables, fibers, etc. you would not be able to tell the difference between a domain and a gole apart from that it seems that at some places many fibers seem to come together. - obviously one of the reasons for the exchanges and gole's is scaling. By going to a gole or exchange you add lots of potential connectivity to your graph as at that gole you can immediately peer with the others at that same exchange. - the real difference is in the policy and operations model. An "open" exchange is supposed to be not involved in the decision for connection two or more of the peers connecting to that exchange (*). That implies legal, economic and administrative ownership roles for the different parties involved as described on the article and talk. Those are different for a GOLE compared to a normal domain. For example in a GOLE to be truly open the administrative ownership of a port should be with the connecting party and not with the owner of the GOLE. That required NRPS systems supporting that, and those are coming around. Path setup requires that both the incoming and outgoing party at a GOLE need to agree that they want to connect before the connectivity in the GOLE can be changed. In a chain of domains one can handle that serially. If that really makes a difference in practical implementations is to be seen and heavily debated between John Vollbrecht and myself ;-). - (*) exception is technical capabilities as a gole could run out of resources or have technical reasons. Another issue is that GOLE's may be placed at locations or financed in such a way that there are restrictions on who can physically connect there (e.g. only not for profit networks NREN's, e.g.). [2004-c-3] Freek Dijkstra, Cees de Laat, "Optical Exchanges", GRIDNETS conference proceedings, oct 2004, http://www.broadnets.org/2004/workshop-papers/Gridnets/DijkstraF.pdf. 13-feb 2005: Internet2 joint techs, Salt Lake City (USA): "What makes an exchange open?". Sheets (pdf) http://staff.science.uva.nl/~delaat/talks/cdl-2005-02-13.pdf So in path computation or topology description there seems not to be a difference in my opinion. In policy and sequence for lightpath setup yes. Best regards, Cees. On Jun 24, 2010, at 8:46 AM, Victor Reijs wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc.
All the best,
Victor
-- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Cees beat me to the punch on the path computation topic. Whether a GOLE is considered a domain itself, or whether it is a node in a larger domain, I think the key attribute in path computation is the high level of inter-domain connectivity a GOLE node represents. The concept of "open" versus "closed" is really just a policy on the resources associated with the GOLE node. The big advantage I see with the GOLE node is that when path computation is performed, inter-domain connections transiting the domain associated with the GOLE node only ever touch the GOLE node. Exposing detailed intra-domain topology to external domains so they can find optimal paths transiting the domain is not really required since they would never leave the GOLE node. John. On 10-06-24 10:37 AM, Cees de Laat wrote:
There are different ways to look at GOLE's or as the initial name was "Open Exchanges". As many of you remember the first mention of this term that I heard in a discussion between Tom DeFanti and Kees Neggers at the Pittsburgh SC prompted me to think about what they meant with the term "Open". That resulted in a study by Freek Dijkstra an Leon Gommans and some others that resulted in an article dwelling into the notion of exchanges, ownership types and policy. See below for one of the articles and talks about this subject.
What does this mean in my opinion: - technically, device wise, there is no difference between domains and goles. If you come from a far planet and you would look at the switches cables, fibers, etc. you would not be able to tell the difference between a domain and a gole apart from that it seems that at some places many fibers seem to come together. - obviously one of the reasons for the exchanges and gole's is scaling. By going to a gole or exchange you add lots of potential connectivity to your graph as at that gole you can immediately peer with the others at that same exchange. - the real difference is in the policy and operations model. An "open" exchange is supposed to be not involved in the decision for connection two or more of the peers connecting to that exchange (*). That implies legal, economic and administrative ownership roles for the different parties involved as described on the article and talk. Those are different for a GOLE compared to a normal domain. For example in a GOLE to be truly open the administrative ownership of a port should be with the connecting party and not with the owner of the GOLE. That required NRPS systems supporting that, and those are coming around. Path setup requires that both the incoming and outgoing party at a GOLE need to agree that they want to connect before the connectivity in the GOLE can be changed. In a chain of domains one can handle that serially. If that really makes a difference in practical implementations is to be seen and heavily debated between John Vollbrecht and myself ;-). - (*) exception is technical capabilities as a gole could run out of resources or have technical reasons. Another issue is that GOLE's may be placed at locations or financed in such a way that there are restrictions on who can physically connect there (e.g. only not for profit networks NREN's, e.g.).
[2004-c-3] Freek Dijkstra, Cees de Laat, "Optical Exchanges", GRIDNETS conference proceedings, oct 2004, http://www.broadnets.org/2004/workshop-papers/Gridnets/DijkstraF.pdf.
13-feb 2005: Internet2 joint techs, Salt Lake City (USA): "What makes an exchange open?". Sheets (pdf) http://staff.science.uva.nl/~delaat/talks/cdl-2005-02-13.pdf
So in path computation or topology description there seems not to be a difference in my opinion. In policy and sequence for lightpath setup yes.
Best regards, Cees.
On Jun 24, 2010, at 8:46 AM, Victor Reijs wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc.
All the best,
Victor
-- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
All, With my work on GIRRA, I distinguish a domain from a GOLE, so that during path computation I remove all non-GOLE domains from the global topology graph before computing a path between "source" domain and "destination" domain. This greatly simplifies the path computation in an ideal global network with GOLEs. In other words, it is assumed that a GOLE is the preferred transient link when conducting path computation between source and destination domains. John, I am not sure I understood your last point about " not leaving the GOLE" ? thanks, Gigi John MacAuley wrote:
Cees beat me to the punch on the path computation topic. Whether a GOLE is considered a domain itself, or whether it is a node in a larger domain, I think the key attribute in path computation is the high level of inter-domain connectivity a GOLE node represents. The concept of "open" versus "closed" is really just a policy on the resources associated with the GOLE node.
The big advantage I see with the GOLE node is that when path computation is performed, inter-domain connections transiting the domain associated with the GOLE node only ever touch the GOLE node. Exposing detailed intra-domain topology to external domains so they can find optimal paths transiting the domain is not really required since they would never leave the GOLE node.
John.
On 10-06-24 10:37 AM, Cees de Laat wrote:
There are different ways to look at GOLE's or as the initial name was "Open Exchanges". As many of you remember the first mention of this term that I heard in a discussion between Tom DeFanti and Kees Neggers at the Pittsburgh SC prompted me to think about what they meant with the term "Open". That resulted in a study by Freek Dijkstra an Leon Gommans and some others that resulted in an article dwelling into the notion of exchanges, ownership types and policy. See below for one of the articles and talks about this subject.
What does this mean in my opinion: - technically, device wise, there is no difference between domains and goles. If you come from a far planet and you would look at the switches cables, fibers, etc. you would not be able to tell the difference between a domain and a gole apart from that it seems that at some places many fibers seem to come together. - obviously one of the reasons for the exchanges and gole's is scaling. By going to a gole or exchange you add lots of potential connectivity to your graph as at that gole you can immediately peer with the others at that same exchange. - the real difference is in the policy and operations model. An "open" exchange is supposed to be not involved in the decision for connection two or more of the peers connecting to that exchange (*). That implies legal, economic and administrative ownership roles for the different parties involved as described on the article and talk. Those are different for a GOLE compared to a normal domain. For example in a GOLE to be truly open the administrative ownership of a port should be with the connecting party and not with the owner of the GOLE. That required NRPS systems supporting that, and those are coming around. Path setup requires that both the incoming and outgoing party at a GOLE need to agree that they want to connect before the connectivity in the GOLE can be changed. In a chain of domains one can handle that serially. If that really makes a difference in practical implementations is to be seen and heavily debated between John Vollbrecht and myself ;-). - (*) exception is technical capabilities as a gole could run out of resources or have technical reasons. Another issue is that GOLE's may be placed at locations or financed in such a way that there are restrictions on who can physically connect there (e.g. only not for profit networks NREN's, e.g.).
[2004-c-3] Freek Dijkstra, Cees de Laat, "Optical Exchanges", GRIDNETS conference proceedings, oct 2004, http://www.broadnets.org/2004/workshop-papers/Gridnets/DijkstraF.pdf.
13-feb 2005: Internet2 joint techs, Salt Lake City (USA): "What makes an exchange open?". Sheets (pdf) http://staff.science.uva.nl/~delaat/talks/cdl-2005-02-13.pdf
So in path computation or topology description there seems not to be a difference in my opinion. In policy and sequence for lightpath setup yes.
Best regards, Cees.
On Jun 24, 2010, at 8:46 AM, Victor Reijs wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc.
All the best,
Victor
-- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
What I meant by "would never leave the GOLE node" is with respect to an inter-domain circuit that is only transiting a domain. In this case both ingress and egress ports would be on the GOLE node and path computation would not seek other routes through that domain. On 10-06-24 11:54 AM, Gigi Karmous-Edwards wrote:
All,
With my work on GIRRA, I distinguish a domain from a GOLE, so that during path computation I remove all non-GOLE domains from the global topology graph before computing a path between "source" domain and "destination" domain. This greatly simplifies the path computation in an ideal global network with GOLEs. In other words, it is assumed that a GOLE is the preferred transient link when conducting path computation between source and destination domains.
John, I am not sure I understood your last point about " not leaving the GOLE" ?
thanks, Gigi
John MacAuley wrote:
Cees beat me to the punch on the path computation topic. Whether a GOLE is considered a domain itself, or whether it is a node in a larger domain, I think the key attribute in path computation is the high level of inter-domain connectivity a GOLE node represents. The concept of "open" versus "closed" is really just a policy on the resources associated with the GOLE node.
The big advantage I see with the GOLE node is that when path computation is performed, inter-domain connections transiting the domain associated with the GOLE node only ever touch the GOLE node. Exposing detailed intra-domain topology to external domains so they can find optimal paths transiting the domain is not really required since they would never leave the GOLE node.
John.
On 10-06-24 10:37 AM, Cees de Laat wrote:
There are different ways to look at GOLE's or as the initial name was "Open Exchanges". As many of you remember the first mention of this term that I heard in a discussion between Tom DeFanti and Kees Neggers at the Pittsburgh SC prompted me to think about what they meant with the term "Open". That resulted in a study by Freek Dijkstra an Leon Gommans and some others that resulted in an article dwelling into the notion of exchanges, ownership types and policy. See below for one of the articles and talks about this subject.
What does this mean in my opinion: - technically, device wise, there is no difference between domains and goles. If you come from a far planet and you would look at the switches cables, fibers, etc. you would not be able to tell the difference between a domain and a gole apart from that it seems that at some places many fibers seem to come together. - obviously one of the reasons for the exchanges and gole's is scaling. By going to a gole or exchange you add lots of potential connectivity to your graph as at that gole you can immediately peer with the others at that same exchange. - the real difference is in the policy and operations model. An "open" exchange is supposed to be not involved in the decision for connection two or more of the peers connecting to that exchange (*). That implies legal, economic and administrative ownership roles for the different parties involved as described on the article and talk. Those are different for a GOLE compared to a normal domain. For example in a GOLE to be truly open the administrative ownership of a port should be with the connecting party and not with the owner of the GOLE. That required NRPS systems supporting that, and those are coming around. Path setup requires that both the incoming and outgoing party at a GOLE need to agree that they want to connect before the connectivity in the GOLE can be changed. In a chain of domains one can handle that serially. If that really makes a difference in practical implementations is to be seen and heavily debated between John Vollbrecht and myself ;-). - (*) exception is technical capabilities as a gole could run out of resources or have technical reasons. Another issue is that GOLE's may be placed at locations or financed in such a way that there are restrictions on who can physically connect there (e.g. only not for profit networks NREN's, e.g.).
[2004-c-3] Freek Dijkstra, Cees de Laat, "Optical Exchanges", GRIDNETS conference proceedings, oct 2004,http://www.broadnets.org/2004/workshop-papers/Gridnets/DijkstraF.pdf.
13-feb 2005: Internet2 joint techs, Salt Lake City (USA): "What makes an exchange open?". Sheets (pdf)http://staff.science.uva.nl/~delaat/talks/cdl-2005-02-13.pdf
So in path computation or topology description there seems not to be a difference in my opinion. In policy and sequence for lightpath setup yes.
Best regards, Cees.
On Jun 24, 2010, at 8:46 AM, Victor Reijs wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc.
All the best,
Victor
-- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web:http://www.heanet.ie/ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, I am not sure that is always the case. I think some GOLEs consist of several network elements and therefore there might be a need for addition intra-domain path computation with in the GOLE. I do agree that the intra-domain path across a GOLE will be much simpler than an intra-domain path across an NREN domain. Gigi John MacAuley wrote:
What I meant by "would never leave the GOLE node" is with respect to an inter-domain circuit that is only transiting a domain. In this case both ingress and egress ports would be on the GOLE node and path computation would not seek other routes through that domain.
On 10-06-24 11:54 AM, Gigi Karmous-Edwards wrote:
All,
With my work on GIRRA, I distinguish a domain from a GOLE, so that during path computation I remove all non-GOLE domains from the global topology graph before computing a path between "source" domain and "destination" domain. This greatly simplifies the path computation in an ideal global network with GOLEs. In other words, it is assumed that a GOLE is the preferred transient link when conducting path computation between source and destination domains.
John, I am not sure I understood your last point about " not leaving the GOLE" ?
thanks, Gigi
John MacAuley wrote:
Cees beat me to the punch on the path computation topic. Whether a GOLE is considered a domain itself, or whether it is a node in a larger domain, I think the key attribute in path computation is the high level of inter-domain connectivity a GOLE node represents. The concept of "open" versus "closed" is really just a policy on the resources associated with the GOLE node.
The big advantage I see with the GOLE node is that when path computation is performed, inter-domain connections transiting the domain associated with the GOLE node only ever touch the GOLE node. Exposing detailed intra-domain topology to external domains so they can find optimal paths transiting the domain is not really required since they would never leave the GOLE node.
John.
On 10-06-24 10:37 AM, Cees de Laat wrote:
There are different ways to look at GOLE's or as the initial name was "Open Exchanges". As many of you remember the first mention of this term that I heard in a discussion between Tom DeFanti and Kees Neggers at the Pittsburgh SC prompted me to think about what they meant with the term "Open". That resulted in a study by Freek Dijkstra an Leon Gommans and some others that resulted in an article dwelling into the notion of exchanges, ownership types and policy. See below for one of the articles and talks about this subject.
What does this mean in my opinion: - technically, device wise, there is no difference between domains and goles. If you come from a far planet and you would look at the switches cables, fibers, etc. you would not be able to tell the difference between a domain and a gole apart from that it seems that at some places many fibers seem to come together. - obviously one of the reasons for the exchanges and gole's is scaling. By going to a gole or exchange you add lots of potential connectivity to your graph as at that gole you can immediately peer with the others at that same exchange. - the real difference is in the policy and operations model. An "open" exchange is supposed to be not involved in the decision for connection two or more of the peers connecting to that exchange (*). That implies legal, economic and administrative ownership roles for the different parties involved as described on the article and talk. Those are different for a GOLE compared to a normal domain. For example in a GOLE to be truly open the administrative ownership of a port should be with the connecting party and not with the owner of the GOLE. That required NRPS systems supporting that, and those are coming around. Path setup requires that both the incoming and outgoing party at a GOLE need to agree that they want to connect before the connectivity in the GOLE can be changed. In a chain of domains one can handle that serially. If that really makes a difference in practical implementations is to be seen and heavily debated between John Vollbrecht and myself ;-). - (*) exception is technical capabilities as a gole could run out of resources or have technical reasons. Another issue is that GOLE's may be placed at locations or financed in such a way that there are restrictions on who can physically connect there (e.g. only not for profit networks NREN's, e.g.).
[2004-c-3] Freek Dijkstra, Cees de Laat, "Optical Exchanges", GRIDNETS conference proceedings, oct 2004, http://www.broadnets.org/2004/workshop-papers/Gridnets/DijkstraF.pdf.
13-feb 2005: Internet2 joint techs, Salt Lake City (USA): "What makes an exchange open?". Sheets (pdf) http://staff.science.uva.nl/~delaat/talks/cdl-2005-02-13.pdf
So in path computation or topology description there seems not to be a difference in my opinion. In policy and sequence for lightpath setup yes.
Best regards, Cees.
On Jun 24, 2010, at 8:46 AM, Victor Reijs wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc.
All the best,
Victor
-- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Gigi Karmous-Edwards wrote:
[...] during path computation I remove all non-GOLE domains from the global topology graph [...]
I am curious why you made this choice. Path computation can take any of these constraints into account: - topology constraints (is there a connection?) - technology constraints (is it compatible?) - usage constraints (is it available?) - policy constraints (may it be used?) Looking at the Internet, BGP is only concerned with the first and last constraint (topology and policy). Let's assume for a moment that in optical networks these are also the most important constraints, then GOLE is much less relevant for path finding (only topology is relevant as it has no policy on its own) than an other domain (topology and policy to take into account). Based on that, I would argue that it is better to leave out the GOLEs and only take other domains into account. Since you do the exact opposite (ignoring non-GOLEs), I presume you argue that other constraints are the ones that matter. Given the other mails, I presume that you only look at topology constraints, ignoring policy, technology and usage constraints. If so, I have two questions: 1. Is there a specific reason why you think that policy, technology and usage constraints can be ignored? 2. Why do you think that topology constraints can be ignored for non-GOLEs? Do you perhaps assume that non-GOLE topologies will never be connected to more than one or two GOLEs and never be connected to a non-GOLE directly? Is this true for larger backbone networks such as GEANT, NLR and Internet2 (I presume that Internet2 is connected to Pacific Wave, StarLight and MAN LAN). Regards, Freek
Hi Freek, I agree that the removal of non-GOLEs from the topology graph is an alternative to creating a constraint during path computation. I thought that the removal from the graph would be easier, similar to removal of failed links (due to availability etc ) during crank-back. Having said that, in GIRRA, both technology and policy is taken into account but availability is not. This is because we do not collect availability information only relatively static information about the topology, therefore reducing complexity and the number or required updates. With reference to your other comments about policy: having an open policy GOLE makes path computation easier, since the fewer "policy-rich " domains one has in the computed path the better. IMHO, an ideal global path will consist of only the source and destination domains and the rest of the path will consist of policy-free GOLEs. Leaving the policy of the path to the two endpoint domains only. Does this make sense? I do realize that this is different than traditional approach and I realize that today in our real world, GOLEs are not all interconnected. The above statements are based on an "ideal" network. Kind regards, Gigi Freek Dijkstra wrote:
Gigi Karmous-Edwards wrote:
[...] during path computation I remove all non-GOLE domains from the global topology graph [...]
I am curious why you made this choice. Path computation can take any of these constraints into account: - topology constraints (is there a connection?) - technology constraints (is it compatible?) - usage constraints (is it available?) - policy constraints (may it be used?)
Looking at the Internet, BGP is only concerned with the first and last constraint (topology and policy). Let's assume for a moment that in optical networks these are also the most important constraints, then GOLE is much less relevant for path finding (only topology is relevant as it has no policy on its own) than an other domain (topology and policy to take into account). Based on that, I would argue that it is better to leave out the GOLEs and only take other domains into account.
Since you do the exact opposite (ignoring non-GOLEs), I presume you argue that other constraints are the ones that matter.
Given the other mails, I presume that you only look at topology constraints, ignoring policy, technology and usage constraints.
If so, I have two questions: 1. Is there a specific reason why you think that policy, technology and usage constraints can be ignored? 2. Why do you think that topology constraints can be ignored for non-GOLEs? Do you perhaps assume that non-GOLE topologies will never be connected to more than one or two GOLEs and never be connected to a non-GOLE directly? Is this true for larger backbone networks such as GEANT, NLR and Internet2 (I presume that Internet2 is connected to Pacific Wave, StarLight and MAN LAN).
Regards, Freek
On 25/06/2010 15:14, Gigi Karmous-Edwards wrote:
I agree that the removal of non-GOLEs from the topology graph is an alternative to creating a constraint during path computation. I thought that the removal from the graph would be easier, similar to removal of failed links (due to availability etc ) during crank-back. Having said that, in GIRRA, both technology and policy is taken into account but availability is not. This is because we do not collect availability information only relatively static information about the topology, therefore reducing complexity and the number or required updates.
Availability is then taken into account using crank-back. As we discussed before, it remains to be seen whether the number of updates regarding availability outnumbers the load on the network due to crank-backs.
With reference to your other comments about policy: having an open policy GOLE makes path computation easier, since the fewer "policy-rich " domains one has in the computed path the better. IMHO, an ideal global path will consist of only the source and destination domains and the rest of the path will consist of policy-free GOLEs. Leaving the policy of the path to the two endpoint domains only. Does this make sense?
This will really depend on the user! I would imagine that LHC Tier-x users do not want to use GOLEs, but instead want to make use of the LHCnet as much as possible. I realise that the LHC is an extreme case, but similar cases can be made for NLR/Internet2, GEANT, GLORIAD and other networks that some but not all users have access to. Leaving policy out of the equation like this may make pathfinding a whole lot simpler, but I'm not sure whether you end up with answers that you can work with.
I do realize that this is different than traditional approach and I realize that today in our real world, GOLEs are not all interconnected. The above statements are based on an "ideal" network.
Given the examples I made above I'm not sure that we'll ever end up with anything resembling an "ideal" network as you describe. Jeroen.
Jeroen, I agree, that if a user has a preference on which domains to include during path computation, then: 1) that should be communicated via the NSI and 2) that the path computation entity computes the path based on user requirements. We might not ever have a completely globally GOLE-interconnected network, however, I do think the roles of GOLEs are different than regular network domains and that in most cases interconnecting domains via GOLEs may result in simpler and shorter paths. Gigi Jeroen van der Ham wrote:
On 25/06/2010 15:14, Gigi Karmous-Edwards wrote:
I agree that the removal of non-GOLEs from the topology graph is an alternative to creating a constraint during path computation. I thought that the removal from the graph would be easier, similar to removal of failed links (due to availability etc ) during crank-back. Having said that, in GIRRA, both technology and policy is taken into account but availability is not. This is because we do not collect availability information only relatively static information about the topology, therefore reducing complexity and the number or required updates.
Availability is then taken into account using crank-back.
As we discussed before, it remains to be seen whether the number of updates regarding availability outnumbers the load on the network due to crank-backs.
With reference to your other comments about policy: having an open policy GOLE makes path computation easier, since the fewer "policy-rich " domains one has in the computed path the better. IMHO, an ideal global path will consist of only the source and destination domains and the rest of the path will consist of policy-free GOLEs. Leaving the policy of the path to the two endpoint domains only. Does this make sense?
This will really depend on the user! I would imagine that LHC Tier-x users do not want to use GOLEs, but instead want to make use of the LHCnet as much as possible. I realise that the LHC is an extreme case, but similar cases can be made for NLR/Internet2, GEANT, GLORIAD and other networks that some but not all users have access to.
Leaving policy out of the equation like this may make pathfinding a whole lot simpler, but I'm not sure whether you end up with answers that you can work with.
I do realize that this is different than traditional approach and I realize that today in our real world, GOLEs are not all interconnected. The above statements are based on an "ideal" network.
Given the examples I made above I'm not sure that we'll ever end up with anything resembling an "ideal" network as you describe.
Jeroen.
So it looks like there are requirements for both resource exclusion and inclusion. Inclusion is a tougher path computation issue. Are we putting this into release 1.0 of the protocol? On 10-06-27 10:20 PM, Gigi Karmous-Edwards wrote:
Jeroen,
I agree, that if a user has a preference on which domains to include during path computation, then: 1) that should be communicated via the NSI and 2) that the path computation entity computes the path based on user requirements.
We might not ever have a completely globally GOLE-interconnected network, however, I do think the roles of GOLEs are different than regular network domains and that in most cases interconnecting domains via GOLEs may result in simpler and shorter paths.
Gigi
Jeroen van der Ham wrote:
On 25/06/2010 15:14, Gigi Karmous-Edwards wrote:
I agree that the removal of non-GOLEs from the topology graph is an alternative to creating a constraint during path computation. I thought that the removal from the graph would be easier, similar to removal of failed links (due to availability etc ) during crank-back. Having said that, in GIRRA, both technology and policy is taken into account but availability is not. This is because we do not collect availability information only relatively static information about the topology, therefore reducing complexity and the number or required updates.
Availability is then taken into account using crank-back.
As we discussed before, it remains to be seen whether the number of updates regarding availability outnumbers the load on the network due to crank-backs.
With reference to your other comments about policy: having an open policy GOLE makes path computation easier, since the fewer "policy-rich " domains one has in the computed path the better. IMHO, an ideal global path will consist of only the source and destination domains and the rest of the path will consist of policy-free GOLEs. Leaving the policy of the path to the two endpoint domains only. Does this make sense?
This will really depend on the user! I would imagine that LHC Tier-x users do not want to use GOLEs, but instead want to make use of the LHCnet as much as possible. I realise that the LHC is an extreme case, but similar cases can be made for NLR/Internet2, GEANT, GLORIAD and other networks that some but not all users have access to.
Leaving policy out of the equation like this may make pathfinding a whole lot simpler, but I'm not sure whether you end up with answers that you can work with.
I do realize that this is different than traditional approach and I realize that today in our real world, GOLEs are not all interconnected. The above statements are based on an "ideal" network.
Given the examples I made above I'm not sure that we'll ever end up with anything resembling an "ideal" network as you describe.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Gigi Karmous-Edwards wrote:
I do realize that this is different than traditional approach and I realize that today in our real world, GOLEs are not all interconnected. The above statements are based on an "ideal" network.
Food for thought: do the networks connect the GOLEs together or do the GOLEs connect the networks together? Both are true, though I usually have the second picture in mind. If this makes a distinction for path finding, I don't know. Out of curiousity, how does GIRRA take policy into account? Freek
I too have the second picture in mind. I assume policy is advertised by each domain, then path computation reads this policy as constraints during path computation. This brings up a question: I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the domain connecting to the GOLE. If this is a true statement, then is there any policy regarding links interconnecting two GOLEs? whose policy is used if both endpoints of this link are policy free GOLEs? Thanks, Gigi Freek Dijkstra wrote:
Gigi Karmous-Edwards wrote:
I do realize that this is different than traditional approach and I realize that today in our real world, GOLEs are not all interconnected. The above statements are based on an "ideal" network.
Food for thought: do the networks connect the GOLEs together or do the GOLEs connect the networks together?
Both are true, though I usually have the second picture in mind. If this makes a distinction for path finding, I don't know.
Out of curiousity, how does GIRRA take policy into account?
Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hello Gigi, Gigi Karmous-Edwards wrote:
I too have the second picture in mind. I assume policy is advertised by each domain, then path computation reads this policy as constraints during path computation.
That is how I would see it indeed. A GOLE will, IMHO, just has a specific property value.
I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the domain connecting to the GOLE. If this is a true statement, then is there any policy regarding links interconnecting two GOLEs? whose policy is used if both endpoints of this link are policy free GOLEs?
So in that case the link is another administrative domain (as it has another policy)? All the best, Victor
Ok, sorry, I meant to say.... I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the policy of the domain that the GOLE is connecting to. Victor, are you saying that the link between two GOLEs will be represented as a autonomous domain? If so, what NSA (NRM) would advertise this small-single-link domain? Whose policy would be advertised? How does this work today with links between Starlight and NetherLight, or ManLAN and StarLight? Gigi Victor Reijs (work) wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
I too have the second picture in mind. I assume policy is advertised by each domain, then path computation reads this policy as constraints during path computation.
That is how I would see it indeed. A GOLE will, IMHO, just has a specific property value.
I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the domain connecting to the GOLE. If this is a true statement, then is there any policy regarding links interconnecting two GOLEs? whose policy is used if both endpoints of this link are policy free GOLEs?
So in that case the link is another administrative domain (as it has another policy)?
All the best,
Victor
Hello Gigi: The way I see this is that a GOLE is policy free, and the policy of the connectivity crossing a GOLE is the "sum" of the policies of the two domains interconnecting/crossconnecting. A link between two GOLEs, such as the IRNC 10G lambda between NetherLight and StarLight as an example, always has an owner: In this case the IRNC project's principle investigator, with his/her policy! Best regards, __ Erik-Jan. On 06/28/2010 12:58 PM, Gigi Karmous-Edwards wrote:
Ok, sorry, I meant to say.... I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the policy of the domain that the GOLE is connecting to.
Victor, are you saying that the link between two GOLEs will be represented as a autonomous domain? If so, what NSA (NRM) would advertise this small-single-link domain? Whose policy would be advertised?
How does this work today with links between Starlight and NetherLight, or ManLAN and StarLight?
Gigi
Victor Reijs (work) wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
I too have the second picture in mind. I assume policy is advertised by each domain, then path computation reads this policy as constraints during path computation.
That is how I would see it indeed. A GOLE will, IMHO, just has a specific property value.
I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the domain connecting to the GOLE. If this is a true statement, then is there any policy regarding links interconnecting two GOLEs? whose policy is used if both endpoints of this link are policy free GOLEs?
So in that case the link is another administrative domain (as it has another policy)?
All the best,
Victor
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
I completely agree with Erik-jan and this is according our earlier research, see my earlier mail. Sent from my iPad On Jun 28, 2010, at 1:04 PM, Erik-Jan Bos <erik-jan.bos@surfnet.nl> wrote:
Hello Gigi:
The way I see this is that a GOLE is policy free, and the policy of the connectivity crossing a GOLE is the "sum" of the policies of the two domains interconnecting/crossconnecting.
A link between two GOLEs, such as the IRNC 10G lambda between NetherLight and StarLight as an example, always has an owner: In this case the IRNC project's principle investigator, with his/her policy!
Best regards,
__
Erik-Jan.
On 06/28/2010 12:58 PM, Gigi Karmous-Edwards wrote:
Ok, sorry, I meant to say.... I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the policy of the domain that the GOLE is connecting to.
Victor, are you saying that the link between two GOLEs will be represented as a autonomous domain? If so, what NSA (NRM) would advertise this small-single-link domain? Whose policy would be advertised?
How does this work today with links between Starlight and NetherLight, or ManLAN and StarLight?
Gigi
Victor Reijs (work) wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
I too have the second picture in mind. I assume policy is advertised by each domain, then path computation reads this policy as constraints during path computation.
That is how I would see it indeed. A GOLE will, IMHO, just has a specific property value.
I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the domain connecting to the GOLE. If this is a true statement, then is there any policy regarding links interconnecting two GOLEs? whose policy is used if both endpoints of this link are policy free GOLEs?
So in that case the link is another administrative domain (as it has another policy)?
All the best,
Victor
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
So, how is this modeled? Victor suggests having the link between two GOLEs as a single domain? How was it done previously? I think the key question that started this debate was: Are GOLEs significantly different from Domains such that we need to model them differently? Or can we use the same object for a domain as GOLE and just add special properties to the object when it is a GOLE? IMHO, I do think the role of GOLEs are different enough that they require a different representation in our topology model. I think this way because of their behavior during path computation. Gigi Cees de Laat wrote:
I completely agree with Erik-jan and this is according our earlier research, see my earlier mail.
Sent from my iPad
On Jun 28, 2010, at 1:04 PM, Erik-Jan Bos <erik-jan.bos@surfnet.nl> wrote:
Hello Gigi:
The way I see this is that a GOLE is policy free, and the policy of the connectivity crossing a GOLE is the "sum" of the policies of the two domains interconnecting/crossconnecting.
A link between two GOLEs, such as the IRNC 10G lambda between NetherLight and StarLight as an example, always has an owner: In this case the IRNC project's principle investigator, with his/her policy!
Best regards,
__
Erik-Jan.
On 06/28/2010 12:58 PM, Gigi Karmous-Edwards wrote:
Ok, sorry, I meant to say.... I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the policy of the domain that the GOLE is connecting to.
Victor, are you saying that the link between two GOLEs will be represented as a autonomous domain? If so, what NSA (NRM) would advertise this small-single-link domain? Whose policy would be advertised?
How does this work today with links between Starlight and NetherLight, or ManLAN and StarLight?
Gigi
Victor Reijs (work) wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
I too have the second picture in mind. I assume policy is advertised by each domain, then path computation reads this policy as constraints during path computation.
That is how I would see it indeed. A GOLE will, IMHO, just has a specific property value.
I assume that if a GOLE is policy free, then the connection between a domain and a GOLE is really based on the domain connecting to the GOLE. If this is a true statement, then is there any policy regarding links interconnecting two GOLEs? whose policy is used if both endpoints of this link are policy free GOLEs?
So in that case the link is another administrative domain (as it has another policy)?
All the best,
Victor
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hello Gigi and others, Gigi Karmous-Edwards wrote:
I think the key question that started this debate was: Are GOLEs significantly different from Domains such that we need to model them differently? Or can we use the same object for a domain as GOLE and just add special properties to the object when it is a GOLE?
I really hope that a 'GOLE' can be an instance of a 'Domain'... But perhaps we need to test this out if we can give the 'Domain' enough richness to cater for this. But I would think if you can define a 'GOLE as a separate object, I am sure one would be able to make it as an instance of a well defined 'Domain';-) Perhaps some good workout examples where this can tested, would be welcome (sometimes I am thinking a little to theoretical; so coming back to the ground is good). Thanks. All the best, Victor
Gigi Karmous-Edwards asked:
So, how is this modeled? Victor suggests having the link between two GOLEs as a single domain?
This is a good approach IMHO. It allows one to add a policy to a link. And as Erik-Jan eloquently pointed out, a link can have a policy.
I think the key question that started this debate was: Are GOLEs significantly different from Domains such that we need to model them differently?
Bearing the KISS principle in mind: If they can be modeled the same way for path finding, then I would do so. That would make the architecture more simple, and thus more powerful. I have not yet seen a compelling reason to model them differently. Such reason might still be there (I can imagine that it would speed up things knowing beforehand that a GOLE has no internal bottlenecks or is policy free.), however, I have not seem a simulation to prove that. Regards, Freek
These are great discussions - From a topology standpoint it seems reasonable to consider that network-domains consist of resources with common control/ ownership. This means that a network such as Internet2's ION, or a GOLE such as NetherLight or a Link owned by a third party are all network domains. This agrees with Freek and Victor - and is what is intended by NSI descriptions. For pathfinding and policy allowing a link to be a separate domain connected to other domains allows the link to have its own policy, enforce by itself. Note that the domain could delegate topology enforcement to one or the other of the domains to which it connects, but it is still its policy that gets enforced. From a control standpoint a GOLE is like any other domain. It makes and breaks connections, and is controlled by its owner. A domain of a single link however seems different - there is no way to control that link, it is on or available all the time. There seems no good way to allow the link to have control of its use if adjacent domains connect to it. I think that if control is required that adjacent domains must have an SLA with the link that requires them to honor the link policy. -- John On Jun 28, 2010, at 8:56 AM, Freek Dijkstra wrote:
Gigi Karmous-Edwards asked:
So, how is this modeled? Victor suggests having the link between two GOLEs as a single domain?
This is a good approach IMHO. It allows one to add a policy to a link. And as Erik-Jan eloquently pointed out, a link can have a policy.
I think the key question that started this debate was: Are GOLEs significantly different from Domains such that we need to model them differently?
Bearing the KISS principle in mind: If they can be modeled the same way for path finding, then I would do so. That would make the architecture more simple, and thus more powerful.
I have not yet seen a compelling reason to model them differently. Such reason might still be there (I can imagine that it would speed up things knowing beforehand that a GOLE has no internal bottlenecks or is policy free.), however, I have not seem a simulation to prove that.
Regards, Freek
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
John, If the link is not dynamically controlled, and requires no additional parties to be contacted for connectivity to be established, then I would agree that the two adjacent nodes could enforce the required policies on the ports terminating the link. John. On 10-06-28 10:47 AM, John Vollbrecht wrote:
A domain of a single link however seems different - there is no way to control that link, it is on or available all the time. There seems no good way to allow the link to have control of its use if adjacent domains connect to it. I think that if control is required that adjacent domains must have an SLA with the link that requires them to honor the link policy.
On Jun 28, 2010, at 1:20 PM, John MacAuley wrote:
John,
If the link is not dynamically controlled, and requires no additional parties to be contacted for connectivity to be established, then I would agree that the two adjacent nodes could enforce the required policies on the ports terminating the link.
Yes, but it is important to note that the adjacent network (not necessarily a node) enforces the policy of the link. This could be done by having the link delegate policy to the adjacent network or by having the adjacent network contact the policy server for the link. In the first case policy is run by the adjacent network for the link, in the second the adjacent network asks for approval from the link. I think this is most important for the provisioning service rather than the scheduling service. It may be that the scheduling can include something that either tells the network what policy to apply for the link or what policy server to ask about the link. I think this complicates things for provisioning -- maybe not if we understand it well enough.
John.
On 10-06-28 10:47 AM, John Vollbrecht wrote:
A domain of a single link however seems different - there is no way to control that link, it is on or available all the time. There seems no good way to allow the link to have control of its use if adjacent domains connect to it. I think that if control is required that adjacent domains must have an SLA with the link that requires them to honor the link policy.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
John Vollbrecht wrote:
[..] A domain of a single link however seems different [..]
[...] it is important to note that the adjacent network (not necessarily a node) enforces the policy of the link. This could be done by having the link delegate policy to the adjacent network or by having the adjacent network contact the policy server for the link. In the first case policy is run by the adjacent network for the link, in the second the adjacent network asks for approval from the link.
This is indeed the crucial question. From an architectural point of view, the former model is the easiest one, as the requester does not need to have knowledge about the delegation is done (the requester directly talks to the owner of the link without worrying how it is enforced). In the later model, the requester ask one domain for resources in another domain, and (presumably?) has to be aware of that. For reasons of simplicity, I prefer the first model. As added advantage is that this seems very similar to how delegation is done for virtual networks. Perhaps related is the question how NSI deals with domains that do not support NSI yet. This is something to consider -- if we create an architecture that only works if all domains in the world deploy it at the same time, then we risk that the deployment takes as long as, say, IPv6. I wonder if the second model you describe above (where a domain enforces the policy of a neighbouring domain that does not support NSI) is applicable to this situation as well. Regards, Freek
On Jun 28, 2010, at 3:02 PM, Freek Dijkstra wrote:
John Vollbrecht wrote:
[..] A domain of a single link however seems different [..]
[...] it is important to note that the adjacent network (not necessarily a node) enforces the policy of the link. This could be done by having the link delegate policy to the adjacent network or by having the adjacent network contact the policy server for the link. In the first case policy is run by the adjacent network for the link, in the second the adjacent network asks for approval from the link.
This is indeed the crucial question. From an architectural point of view, the former model is the easiest one, as the requester does not need to have knowledge about the delegation is done (the requester directly talks to the owner of the link without worrying how it is enforced). In the later model, the requester ask one domain for resources in another domain, and (presumably?) has to be aware of that.
For reasons of simplicity, I prefer the first model. As added advantage is that this seems very similar to how delegation is done for virtual networks.
It seems to me that the first model has some problems that might make it harder. The biggest is that it has to delegate policy for its domain to another domain. It is not clear how to do this in a standard way - perhaps XACML could be used to define policy and send it to the enforcing domain. The alternative - having the enforcing domain query the link's policy requires knowing how to question the other domain policy server. This is pretty much what happens during connection reservation where there is no enforcement other than by provider NSAs accepting or rejecting a request. Either way requires an SLA between enforcing domain and adjacent domain - one domain must trust that the other will enforce policy as agreed. My thinking is that either of these ways might be best - perhaps in different situations. Some specific use cases would help. John
Perhaps related is the question how NSI deals with domains that do not support NSI yet. This is something to consider -- if we create an architecture that only works if all domains in the world deploy it at the same time, then we risk that the deployment takes as long as, say, IPv6. I wonder if the second model you describe above (where a domain enforces the policy of a neighbouring domain that does not support NSI) is applicable to this situation as well.
Regards, Freek
Quick question that may be related. How would we model a client routing policy? For example, my organization has a policy against routing over links from another organization and I am requesting a schedule from the network. How does the NSA learn of this policy? I would assume it is a similar issue to specifying SLRG values, and the requesting client would specify the domain for exclusion. John. On 10-06-28 7:16 PM, John Vollbrecht wrote:
On Jun 28, 2010, at 3:02 PM, Freek Dijkstra wrote:
John Vollbrecht wrote:
[..] A domain of a single link however seems different [..]
[...] it is important to note that the adjacent network (not necessarily a node) enforces the policy of the link. This could be done by having the link delegate policy to the adjacent network or by having the adjacent network contact the policy server for the link. In the first case policy is run by the adjacent network for the link, in the second the adjacent network asks for approval from the link.
This is indeed the crucial question. From an architectural point of view, the former model is the easiest one, as the requester does not need to have knowledge about the delegation is done (the requester directly talks to the owner of the link without worrying how it is enforced). In the later model, the requester ask one domain for resources in another domain, and (presumably?) has to be aware of that.
For reasons of simplicity, I prefer the first model. As added advantage is that this seems very similar to how delegation is done for virtual networks.
It seems to me that the first model has some problems that might make it harder. The biggest is that it has to delegate policy for its domain to another domain. It is not clear how to do this in a standard way - perhaps XACML could be used to define policy and send it to the enforcing domain.
The alternative - having the enforcing domain query the link's policy requires knowing how to question the other domain policy server. This is pretty much what happens during connection reservation where there is no enforcement other than by provider NSAs accepting or rejecting a request.
Either way requires an SLA between enforcing domain and adjacent domain - one domain must trust that the other will enforce policy as agreed.
My thinking is that either of these ways might be best - perhaps in different situations. Some specific use cases would help.
John
Perhaps related is the question how NSI deals with domains that do not support NSI yet. This is something to consider -- if we create an architecture that only works if all domains in the world deploy it at the same time, then we risk that the deployment takes as long as, say, IPv6. I wonder if the second model you describe above (where a domain enforces the policy of a neighbouring domain that does not support NSI) is applicable to this situation as well.
Regards, Freek
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hello John, I see the client end system (including its routing policy, etc.) also as a domain. For me there is no real different between a 'Linking domain' and a 'User domain'. Except that a User domain only has an egress *or* an ingress (while a Linking domain has an egress *and* an ingress port). I don't yet know if it are different objects and different instantiations of 'Domain'. In the Stitching Framework they are different instantiations. But there is a difference (like with your policies): A User domain can convey the requirements on the path (both policy, but also end-to-end SLA/performance/etc.), beside its internals (like actual delay, etc. only inside the domain). But perhaps a Linking Domain in general could even also make such 'demands' on the path (like "I only want to link if that GOLE/NREN in an other continent takes part"). All the best, Victor John MacAuley wrote:
Quick question that may be related. How would we model a client routing policy? For example, my organization has a policy against routing over links from another organization and I am requesting a schedule from the network. How does the NSA learn of this policy? I would assume it is a similar issue to specifying SLRG values, and the requesting client would specify the domain for exclusion.
John.
On 10-06-28 7:16 PM, John Vollbrecht wrote:
On Jun 28, 2010, at 3:02 PM, Freek Dijkstra wrote:
John Vollbrecht wrote:
[..] A domain of a single link however seems different [..]
[...] it is important to note that the adjacent network (not necessarily a node) enforces the policy of the link. This could be done by having the link delegate policy to the adjacent network or by having the adjacent network contact the policy server for the link. In the first case policy is run by the adjacent network for the link, in the second the adjacent network asks for approval from the link.
This is indeed the crucial question. From an architectural point of view, the former model is the easiest one, as the requester does not need to have knowledge about the delegation is done (the requester directly talks to the owner of the link without worrying how it is enforced). In the later model, the requester ask one domain for resources in another domain, and (presumably?) has to be aware of that.
For reasons of simplicity, I prefer the first model. As added advantage is that this seems very similar to how delegation is done for virtual networks.
It seems to me that the first model has some problems that might make it harder. The biggest is that it has to delegate policy for its domain to another domain. It is not clear how to do this in a standard way - perhaps XACML could be used to define policy and send it to the enforcing domain.
The alternative - having the enforcing domain query the link's policy requires knowing how to question the other domain policy server. This is pretty much what happens during connection reservation where there is no enforcement other than by provider NSAs accepting or rejecting a request.
Either way requires an SLA between enforcing domain and adjacent domain - one domain must trust that the other will enforce policy as agreed.
My thinking is that either of these ways might be best - perhaps in different situations. Some specific use cases would help.
John
Perhaps related is the question how NSI deals with domains that do not support NSI yet. This is something to consider -- if we create an architecture that only works if all domains in the world deploy it at the same time, then we risk that the deployment takes as long as, say, IPv6. I wonder if the second model you describe above (where a domain enforces the policy of a neighbouring domain that does not support NSI) is applicable to this situation as well.
Regards, Freek
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hello John, John Vollbrecht wrote:
Yes, but it is important to note that the adjacent network (not necessarily a node) enforces the policy of the link. This could be done by having the link delegate policy to the adjacent network or by having the adjacent network contact the policy server for the link.
I think delegation is not really important. For me it important who sets and is responsible at the end for the policy. If one delegates something, the responsibility is not delegated, IMHO. So I would uncouple 'delegation' from 'who sets the policy'. And lets have a method 'how to delegate policies' as that (understanding from the e-mails) will also always be needed. All the best, Victor
This has been a good discussion. The issues brought up so far are (and my take based on responses as well as my own opinion) : 1. In Topology representation, is there a need to differentiate a GOLE from a Network/Domain? - the consensus seems to be a "No". It seems that topologically there is no difference between a GOLE and a Domain 2. I need to include a particular domain? How do I specify that to the path computing engine in NSI? - The inclusion of domains can be done via the same concept as an ERO. You can ask for a partial ERO that puts those particular path constraints on the path computation decision. You could specify that you want to use a particular GOLE using a partial ERO. NSI should support asking for paths with EROs specified (which version up for discussion) 3. There may be different policies associated with a particular network (domain, link, open-exchange, etc). How and where does that have bearing on the whole path computation process? - In the tree/chain model, each network domain being transitioned has the need to do their own intra-domain path computation. In order to do that, it has to apply the policies of the domain. The Service Plane architecture allows many different points in the reservation process to apply local policies. The first is when a user sends a service request to a NSA Provider Agent. The agent can apply policies based on egress/ingress ports requested through that domain and accept/ reject the connection. Similarly the PCE model allows for a series of decisions to take place based on constraints till a workable alternative is clear. Distributing policies of links/connections between domains is inherently a very complex process and should be avoided. I would rather we focus on network capabilities instead. Inder On Jun 28, 2010, at 5:56 AM, Freek Dijkstra wrote:
Gigi Karmous-Edwards asked:
So, how is this modeled? Victor suggests having the link between two GOLEs as a single domain?
This is a good approach IMHO. It allows one to add a policy to a link. And as Erik-Jan eloquently pointed out, a link can have a policy.
I think the key question that started this debate was: Are GOLEs significantly different from Domains such that we need to model them differently?
Bearing the KISS principle in mind: If they can be modeled the same way for path finding, then I would do so. That would make the architecture more simple, and thus more powerful.
I have not yet seen a compelling reason to model them differently. Such reason might still be there (I can imagine that it would speed up things knowing beforehand that a GOLE has no internal bottlenecks or is policy free.), however, I have not seem a simulation to prove that.
Regards, Freek
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hello Gigi, Gigi Karmous-Edwards wrote:
Victor, are you saying that the link between two GOLEs will be represented as a autonomous domain? If so, what NSA (NRM) would advertise this small-single-link domain? Whose policy would be advertised?
I can imagine that there are two GOLE (say one on two different continents) and a link that is provided by a certainty entity which only wants to transport traffic of its kind over it (say an LHCOPN link [if I make the wrong example, I am sure there one could make another one]. We are talking about abstracted domains, so a link is a very nice abstracted domain with two ports (both allowing in and egress). So in that case this link (which is for me an administrative domain) will have its own policies attached. Hope my few cents help? All the best, Victor
Hi John, See inline: On Jun 24, 2010, at 10:24 AM, John MacAuley wrote:
Cees beat me to the punch on the path computation topic. Whether a GOLE is considered a domain itself, or whether it is a node in a larger domain, I think the key attribute in path computation is the high level of inter-domain connectivity a GOLE node represents. The concept of “open” versus “closed” is really just a policy on the resources associated with the GOLE node.
Correct. Where and when policy goes in the path computation depends on the algorithm. Do you search for any path or for any path "Cees de Laat" is allowed to use, etc. I do not see a way to think of path computation code that has a statement: If (I enter a GOLE) then I do this Else I do that Endif The high connectivity will implicitly present itself as statistically easy to find paths through GOLE's but if it were well connected domains; so what.
The big advantage I see with the GOLE node is that when path computation is performed, inter-domain connections transiting the domain associated with the GOLE node only ever touch the GOLE node. Exposing detailed intra-domain topology to external domains so they can find optimal paths transiting the domain is not really required since they would never leave the GOLE node.
This should be true if GOLE's are geographically point like objects. Two possible exceptions: - multi technology GOLE may have some more internal structure - distributed GOLE that says "if you connect anywhere to us you can exit anywhere else. I seem to remember CENIC regarded their network that way. Obviously then the whole Administrative ownership delegation and policy structure is then important to precisely define... For sake of discussion I would at this point not want to discuss distributed GOLE's. Exposing intradomain topology is only needed when part of that topology is used for interdomain links. For example if SURFnet regards the dark fiber AMS-CERN as their domain, then that is intradomain topology (or not?). Best regards, Cees.
John.
On 10-06-24 10:37 AM, Cees de Laat wrote:
There are different ways to look at GOLE's or as the initial name was "Open Exchanges". As many of you remember the first mention of this term that I heard in a discussion between Tom DeFanti and Kees Neggers at the Pittsburgh SC prompted me to think about what they meant with the term "Open". That resulted in a study by Freek Dijkstra an Leon Gommans and some others that resulted in an article dwelling into the notion of exchanges, ownership types and policy. See below for one of the articles and talks about this subject.
What does this mean in my opinion: - technically, device wise, there is no difference between domains and goles. If you come from a far planet and you would look at the switches cables, fibers, etc. you would not be able to tell the difference between a domain and a gole apart from that it seems that at some places many fibers seem to come together. - obviously one of the reasons for the exchanges and gole's is scaling. By going to a gole or exchange you add lots of potential connectivity to your graph as at that gole you can immediately peer with the others at that same exchange. - the real difference is in the policy and operations model. An "open" exchange is supposed to be not involved in the decision for connection two or more of the peers connecting to that exchange (*). That implies legal, economic and administrative ownership roles for the different parties involved as described on the article and talk. Those are different for a GOLE compared to a normal domain. For example in a GOLE to be truly open the administrative ownership of a port should be with the connecting party and not with the owner of the GOLE. That required NRPS systems supporting that, and those are coming around. Path setup requires that both the incoming and outgoing party at a GOLE need to agree that they want to connect before the connectivity in the GOLE can be changed. In a chain of domains one can handle that serially. If that really makes a difference in practical implementations is to be seen and heavily debated between John Vollbrecht and myself ;-). - (*) exception is technical capabilities as a gole could run out of resources or have technical reasons. Another issue is that GOLE's may be placed at locations or financed in such a way that there are restrictions on who can physically connect there (e.g. only not for profit networks NREN's, e.g.).
[2004-c-3] Freek Dijkstra, Cees de Laat, "Optical Exchanges", GRIDNETS conference proceedings, oct 2004, http://www.broadnets.org/2004/workshop-papers/Gridnets/DijkstraF.pdf .
13-feb 2005: Internet2 joint techs, Salt Lake City (USA): "What makes an exchange open?". Sheets (pdf) http://staff.science.uva.nl/~delaat/talks/cdl-2005-02-13.pdf
So in path computation or topology description there seems not to be a difference in my opinion. In policy and sequence for lightpath setup yes.
Best regards, Cees.
On Jun 24, 2010, at 8:46 AM, Victor Reijs wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc.
All the best,
Victor
-- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
_______________________________________________ nsi-wg mailing list
nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list
nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi Gigi-restr I believe a GOLE has two properties that are interesting, but which I do not believe distinguish it architecturally from a conventional network or domain: 1) It has an "open" policy. 2) it encourages the interconnection of GOLEs in order to allow "express" paths across geographic space to other domains Allow me to elaborate... As for the "open" policy of a GOLE, the fact that the sponsors of the GOLE associate a null policy administrative policy to a switch does not architecturally change the "network" model it conforms to. Even if you express the open nature of a GOLE by attaching no particular policy to the resource, this only means the PathFnder has less work to do - it does not (IMO) change the technical architecture of the domain containing the GOLE as a switching point that must still be coordinated via a control plane of some sort. It does not change the pathfinding process - it just reduces some of the constraints. If the GOLE - or a interconnected group of GOLEs - exhibit some "better" path characteristic than conventional networks, it will be expressed in the topology advertised and will result in GOLE based paths emerging from the PathFinding process. But this would be true for *any* network. If we relate this to our NSI model, a GOLE is represented no differnetly than any other "network" - it has a set of STPs and offers some transfer function as defined by its advertised topology. A local NSA would still be required to be associated with the GOLE and it would still require an NRM to actually interact with the switching device. So, and this is a Good Thing, a GOLE is no differnet from other networks except by merit of the fact that the internal authorization policy is highly permissive. The corrolary is that any network that had a similar open policy would constitute a GOLE. Right? WRT the second point above, I think one of the practical advantages of our notion of a GOLE is to create an open (policywise) "express lane" across the global geographic reach of the R&E infrastrucutre. I.e. by transitting GOLEs - or open exchange points - with big pipes interconencting these exchange point domains, we are able to bypass a significant amount of intervening networks, switching hardware, restrictive (and often antiquated) policy, and complexity. THis too is a Good Thing. But again, from a PathFinder's point of view doing a constraint based search of available paths, this express lane will (should) only emerge by walking the topology and pruning more expensive paths. If a GOLE based path is emergent as the "best" available path, it will be used. If you wish to force a request to use a GOLE, you can do so by specifying a GOLE transit STP within the request, but then one would question the value of the GOLE if -after looking at all paths - the PathFinder must be forced to use it - i.e. why does PathFinding prefer another path? IMO, a GOLE (or any exchange point path) should exhibit sufficient advantage via the path computation to justify its selection as the prefered path. And so, it exhibits no special architectural characteristics from other network domains. So, while I support the notion of AUP free exchange points and Big Pipes in bewteen as a Best Common Practice, I do not see any compelling reason to consider GOLEs as somehow unique within the more general inter-domain service architecture. Hope this made some sense:-) Jerry Victor Reijs wrote:
Hello Gigi,
Gigi Karmous-Edwards wrote:
True, it is a domain. However, if a GOLE has the property of being "open policy" and its main service is to interconnect paths between GOLEs and domains, then from a "strictly" path computation perspective, and if given a choice between a transient link across a domain w/ policy or through an open policy GOLE, then it seems that the path computation entity will find it simpler to choose the the path through the GOLE rather than the domain. What are your thoughts on this particular scenario...
Perhaps I have no full solution to the problem, but IMHO it would be great if we can define the properties of a GOLE to any Domain. So the main question is: are 'GOLE' and 'Domain' different objects, or are they the same object (different instances) with different attribute values. I would prefer the last one as it provide a larger flexibility (e.g. a 'Domain' can be a 'GOLE' in context or when time changes)
I can see a situation where an end user may choose to go through a particular domain if they are members of a domain and have certain privileges.
This is not only related to policy, might also be QoS, etc.
All the best,
Victor
participants (11)
-
Cees de Laat -
Erik-Jan Bos -
Freek Dijkstra -
Gigi Karmous-Edwards -
Inder Monga -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley -
John Vollbrecht -
Victor Reijs -
Victor Reijs (work)