Re: [Nsi-wg] Topology Abstract sent to Terena
Hello, I have the feeling this discussion is not going anywhere. We have been trading arguments for a couple of months now, and neither side seems to be moving. I have the feeling that it may be better to put this to the vote. Jeroen. On 11 Dec 2011, at 23:09, Jerry Sobieski wrote:
Hey Jeroen - I will try to make my discussion more succinct:-)
On 12/11/11 12:36 PM, Jeroen van der Ham wrote:
Hi,
Jerry, please make shorter arguments. I think this is an important discussion, but I cannot dedicate all my time to reading your emails. Your point below could have been made a lot more succinctly.
Mapping different labels and/or layers (VLANs in this case) to different network representations has been studied before.[1] It has the advantage of making pathfinding somewhat simpler, at the cost of generating those representations. There are two problems with it: - it makes the network representation a lot more complex, making it a lot harder to diagnose problems. The topology *is* complex - simplification means topology hiding and delegation. Keep in mind we are not looking for an /optimal /path - we are simply looking for any _/acceptable/_ path, one that meets a set of specific constraints provided by the RA. _/Any/_ path will do as long as it meets those constraints. Thus, we can define network regions and perform the high level interdomain path selection based upon adjacency and segment Reservations. And then go to the NSAs along a candidate path to check the resources and reserve the segments. _/The external inter-domain PF does not need to know the details/_ - we let the local internal NSA (and ultimately the NRM) deal with those. The adaptations and multilayer incompatibilities are expressed in the topology by simple connectivity at a node. You have to do it somewhere. With the proper abstractions and architecture, it all will all come out in the wash.
As for diagnosing "problems" - I am not concerned about large topologies. That is the price of admission. If you mean just debugging a large topology file itself...well, these will be autogenerated with tools or the NSAs themselves, and built up from smaller more local views, so I am not worried about generating correct topology. I am more concerned with insuring the topological model allows large topologies to be practical (!) We need to make sure the algebra of combining smaller more manageable topology files to create larger complex topologies in both scope and detail is provably correct. And that we can hide topology where necessary or desired for scaling, security, etc. - and things still work.
We need NSI to define the canonical form of a "Connection" and "Service Termination Point", the "Network Service" node and a generic NSI Topology model. And let the technology specific aspects be handled by the NRMs or map themselves to NSI constructs. We can leverage principles of object oriented design to define generic topological objects that expose more topologically significant functions while hiding hardware specific details and which present common easily modeled nodal functions for external pathfinders. I look forward to this as it will allow us to encode network nodes that do encapsulation/decapsulation, stacking (virtual layer) functions, switching, muxing/demuxing, etc. To do this, we have to start at the high level (inter-domain) and work our way down to more detailed nodes. Yes, the topology will get bigger - but how big is too big? I dunno - but we have a ways to go before its too large. And at what detail do we stop and say...hmm, lets just define an agent to check feasibility, availability, and allocation for this topological region. At the high level, it works using the NSA as the agent, the any-to-any (A2A) transit function for NSI Networks, and the atomic check-reserve semantic of the CS ReservationRequest.
- you get multiple representations of the same link, which have an inter-dependency. You want to represent that the link can carry 10Gb, yet not all of the VLANs can carry 10Gb at the same time. This is an example of shared resource dependencies. Bandwidth is only one example. Common ethernet per-box VLAN scoping is another example of a resource that is shared across multiple physical links, buffer management is often shared at blade levels rather than a single physical port, Shared Risk Link Groups (SRLG), and even more complex shared resources based on authorization limits is another. So what you point out is true, but it is a much broader issue and not solved by simply dealing with VLANs on a physical port. Even with that one example, one could easily imagine a situation where some VLANs on a port are statically routed to one network, and other vlans on the same physical port go to a different real network. (We did this very thing at the FIA demos in October !). We need a more general approach to resource mapping.
I think the way to represent these shared resources might be to have a "grouping" node that identifies a resource (say bandwidth) that is shared among members of that group. I have been trying to think this through... As we have the NSI Topology defined now, such sharing is magically handled by the NSA, its all done internal to the respective networks.
Best regards! Jerry
Jeroen.
[1]: Path selection in multi-layer networks, Fernando Kuipers, Freek Dijkstra: http://staff.science.uva.nl/~fdijkstr/publications/multilayer-pathselection....
On 11 Dec 2011, at 17:55, Jerry Sobieski wrote:
Hi Jeroen-
See attached slides... (just two simple slides)
My point was that if you cannot ever swap between two particular endpoints (portx/vlan100 and porty/vlan101) then those two particular endpoints should not be advertised as being part a network service that says it can do "any to any" switching - it can't. If you advertise this cross-connect capability (as we do implicitly), then you entice and invite remote agents to take advantage of that capability - one which internally you knew all the time was never possible - ever. That seems dis-ingenuous to me at best, and malicious in some worst case. Why not just advertise 1000 Gbps capability as well? And this actually causes the "exhaustive search" problem.
This does not mean that the remaining flat vlan switching capability is not important and useful. Take StarLight for instance, it had four convergent physical links: JGN,KRL,NL, and ESN. Each with the four VLANs. Even though SL could not swap VLAN IDs in the process of switching VLANs, it could still switch VLANs nontheless. So, A VLAN 100 from JGN could in fact switch to either of the other three destinations KRL/vlan100, NL/vlan100, or ESN/vlan100 but it all cases it retains the same VLAN 100. So a non-swapping switch still provides important conventional forwarding/crossconnect switching capability. As it was, by advertising SL as a single physical Network rather than four separate Network Services we created the problem of 75% of advertised routes were impossible.
So we could have defined four VLAN planes SL80, SL81, SL82, SL83 -> each as a separate NSI Network, and each would have had four adjacencies. And those established and advertised adjacencies (SDPs) will have been mapped apriori to the associated VLANs in both adjacent networks. If the adjacent network is also "VLAN challenged" the dependencies would have already been expressed in their [internal] topology in a similar fashion as well. If those adjacent networks were label swapping, then all four endpoints SL80:PS80, SL81:PS81, etc would have converged on the same NSI Network as they do now...indicating that the adjacent network can route the circuit between STPs with different VLAN IDs.
So in fact, just because a switch or a network cannot do VLAN swapping does not mean it cannot do switching - and there is still important value in this capability. By subdividing the challenged Networks into the appropriate VLAN planes, we express the very topological routing information you want. And it did not require any changes to the PFs in other networks - and it did not actually require knowledge of the particular VLANs labels or any physical technology information.
One last point: The mingling of impossible cross-connects is externally indistinguishable from simple internal resource exhaustion. In terms of asking for a Reservation, if the route is impossible or if there is just not enough bandwidth, we still just get a reject. So the question is: If we run out of resources and some crossconnects become "highly improbable" (but not strictly impossible) should we revoke those advertisements on the same grounds that we don't advertise impossible crossconnects? Possibly...:-) How long time will the "improbable" cross connects remain "improbable"? If a cross connect is highly unlikely (e.g. Someone has reserved all 10 Gbps on a 10G path for 6 months...) is it misleading to continue advertsing it? This is where state updates become important and a grey area comes in...
Hope this helps. Jerry
On 12/10/11 2:16 PM, Jeroen van der Ham wrote:
On 10 Dec 2011, at 20:13, Jeroen van der Ham wrote:
<tirade> With respect to VLAN swapping... Inability to swap VLANs is essentially saying your NSI network cannot cross connect - ever - certain STPs. If you cannot *ever* cross connect certain STPs, there is no service! I might as well advertise STPs that point to bananas - I will never be able crossconnect them either but who cares? Advertising capabilities that can never be met is a Bad Thing. It injects false and misleading topological information - it could be considered malicious(!) Sorry, I'm calling bullshit on that one.
In the Automated GOLE topology we currently have 0 networks that are able to do VLAN swapping. Netherlight does have that capability, but due to how things are connected, it is not available for the Automated GOLE topology.
If we cannot even provide a connection service on an existing network, then we have no connection service.
Jeroen. <VLAN Planes.pptx>
Jeroen - *I* think we are making significant progress on topology. And I believe we *are* converging on solutions that will accommodate all of these needs. This is not a simple issue. This is a discussion where we are trying to find _/consensus/_. Where there may be several potential solutions to an issue, we try to find a compromise solution where multiple aspects may be accommodated. This is how this group seems to work best, and has made considerable and successful progress in that fashion. I know hashing through this stuff is slow and painful, but the results have been good... It gets everyone on the same page and gets everyone to agree...which, for a *standard*, is crucial. So please don't get frustrated or annoyed - we need to work through these issues and find that compromise. We are close. I do not think a vote will resolve the issues. Jerry On 12/12/11 3:27 AM, Jeroen van der Ham wrote:
Hello,
I have the feeling this discussion is not going anywhere. We have been trading arguments for a couple of months now, and neither side seems to be moving. I have the feeling that it may be better to put this to the vote.
Jeroen.
On 11 Dec 2011, at 23:09, Jerry Sobieski wrote:
Hey Jeroen - I will try to make my discussion more succinct:-)
On 12/11/11 12:36 PM, Jeroen van der Ham wrote:
Hi,
Jerry, please make shorter arguments. I think this is an important discussion, but I cannot dedicate all my time to reading your emails. Your point below could have been made a lot more succinctly.
Mapping different labels and/or layers (VLANs in this case) to different network representations has been studied before.[1] It has the advantage of making pathfinding somewhat simpler, at the cost of generating those representations. There are two problems with it: - it makes the network representation a lot more complex, making it a lot harder to diagnose problems. The topology *is* complex - simplification means topology hiding and delegation. Keep in mind we are not looking for an /optimal /path - we are simply looking for any _/acceptable/_ path, one that meets a set of specific constraints provided by the RA. _/Any/_ path will do as long as it meets those constraints. Thus, we can define network regions and perform the high level interdomain path selection based upon adjacency and segment Reservations. And then go to the NSAs along a candidate path to check the resources and reserve the segments. _/The external inter-domain PF does not need to know the details/_ - we let the local internal NSA (and ultimately the NRM) deal with those. The adaptations and multilayer incompatibilities are expressed in the topology by simple connectivity at a node. You have to do it somewhere. With the proper abstractions and architecture, it all will all come out in the wash.
As for diagnosing "problems" - I am not concerned about large topologies. That is the price of admission. If you mean just debugging a large topology file itself...well, these will be autogenerated with tools or the NSAs themselves, and built up from smaller more local views, so I am not worried about generating correct topology. I am more concerned with insuring the topological model allows large topologies to be practical (!) We need to make sure the algebra of combining smaller more manageable topology files to create larger complex topologies in both scope and detail is provably correct. And that we can hide topology where necessary or desired for scaling, security, etc. - and things still work.
We need NSI to define the canonical form of a "Connection" and "Service Termination Point", the "Network Service" node and a generic NSI Topology model. And let the technology specific aspects be handled by the NRMs or map themselves to NSI constructs. We can leverage principles of object oriented design to define generic topological objects that expose more topologically significant functions while hiding hardware specific details and which present common easily modeled nodal functions for external pathfinders. I look forward to this as it will allow us to encode network nodes that do encapsulation/decapsulation, stacking (virtual layer) functions, switching, muxing/demuxing, etc. To do this, we have to start at the high level (inter-domain) and work our way down to more detailed nodes. Yes, the topology will get bigger - but how big is too big? I dunno - but we have a ways to go before its too large. And at what detail do we stop and say...hmm, lets just define an agent to check feasibility, availability, and allocation for this topological region. At the high level, it works using the NSA as the agent, the any-to-any (A2A) transit function for NSI Networks, and the atomic check-reserve semantic of the CS ReservationRequest.
- you get multiple representations of the same link, which have an inter-dependency. You want to represent that the link can carry 10Gb, yet not all of the VLANs can carry 10Gb at the same time. This is an example of shared resource dependencies. Bandwidth is only one example. Common ethernet per-box VLAN scoping is another example of a resource that is shared across multiple physical links, buffer management is often shared at blade levels rather than a single physical port, Shared Risk Link Groups (SRLG), and even more complex shared resources based on authorization limits is another. So what you point out is true, but it is a much broader issue and not solved by simply dealing with VLANs on a physical port. Even with that one example, one could easily imagine a situation where some VLANs on a port are statically routed to one network, and other vlans on the same physical port go to a different real network. (We did this very thing at the FIA demos in October !). We need a more general approach to resource mapping.
I think the way to represent these shared resources might be to have a "grouping" node that identifies a resource (say bandwidth) that is shared among members of that group. I have been trying to think this through... As we have the NSI Topology defined now, such sharing is magically handled by the NSA, its all done internal to the respective networks.
Best regards! Jerry
Jeroen.
[1]: Path selection in multi-layer networks, Fernando Kuipers, Freek Dijkstra: http://staff.science.uva.nl/~fdijkstr/publications/multilayer-pathselection....
On 11 Dec 2011, at 17:55, Jerry Sobieski wrote:
Hi Jeroen-
See attached slides... (just two simple slides)
My point was that if you cannot ever swap between two particular endpoints (portx/vlan100 and porty/vlan101) then those two particular endpoints should not be advertised as being part a network service that says it can do "any to any" switching - it can't. If you advertise this cross-connect capability (as we do implicitly), then you entice and invite remote agents to take advantage of that capability - one which internally you knew all the time was never possible - ever. That seems dis-ingenuous to me at best, and malicious in some worst case. Why not just advertise 1000 Gbps capability as well? And this actually causes the "exhaustive search" problem.
This does not mean that the remaining flat vlan switching capability is not important and useful. Take StarLight for instance, it had four convergent physical links: JGN,KRL,NL, and ESN. Each with the four VLANs. Even though SL could not swap VLAN IDs in the process of switching VLANs, it could still switch VLANs nontheless. So, A VLAN 100 from JGN could in fact switch to either of the other three destinations KRL/vlan100, NL/vlan100, or ESN/vlan100 but it all cases it retains the same VLAN 100. So a non-swapping switch still provides important conventional forwarding/crossconnect switching capability. As it was, by advertising SL as a single physical Network rather than four separate Network Services we created the problem of 75% of advertised routes were impossible.
So we could have defined four VLAN planes SL80, SL81, SL82, SL83 -> each as a separate NSI Network, and each would have had four adjacencies. And those established and advertised adjacencies (SDPs) will have been mapped apriori to the associated VLANs in both adjacent networks. If the adjacent network is also "VLAN challenged" the dependencies would have already been expressed in their [internal] topology in a similar fashion as well. If those adjacent networks were label swapping, then all four endpoints SL80:PS80, SL81:PS81, etc would have converged on the same NSI Network as they do now...indicating that the adjacent network can route the circuit between STPs with different VLAN IDs.
So in fact, just because a switch or a network cannot do VLAN swapping does not mean it cannot do switching - and there is still important value in this capability. By subdividing the challenged Networks into the appropriate VLAN planes, we express the very topological routing information you want. And it did not require any changes to the PFs in other networks - and it did not actually require knowledge of the particular VLANs labels or any physical technology information.
One last point: The mingling of impossible cross-connects is externally indistinguishable from simple internal resource exhaustion. In terms of asking for a Reservation, if the route is impossible or if there is just not enough bandwidth, we still just get a reject. So the question is: If we run out of resources and some crossconnects become "highly improbable" (but not strictly impossible) should we revoke those advertisements on the same grounds that we don't advertise impossible crossconnects? Possibly...:-) How long time will the "improbable" cross connects remain "improbable"? If a cross connect is highly unlikely (e.g. Someone has reserved all 10 Gbps on a 10G path for 6 months...) is it misleading to continue advertsing it? This is where state updates become important and a grey area comes in...
Hope this helps. Jerry
On 12/10/11 2:16 PM, Jeroen van der Ham wrote:
On 10 Dec 2011, at 20:13, Jeroen van der Ham wrote:
> <tirade> > With respect to VLAN swapping... Inability to swap VLANs is essentially saying your NSI network cannot cross connect - ever - certain STPs. If you cannot *ever* cross connect certain STPs, there is no service! I might as well advertise STPs that point to bananas - I will never be able crossconnect them either but who cares? Advertising capabilities that can never be met is a Bad Thing. It injects false and misleading topological information - it could be considered malicious(!) Sorry, I'm calling bullshit on that one.
In the Automated GOLE topology we currently have 0 networks that are able to do VLAN swapping. Netherlight does have that capability, but due to how things are connected, it is not available for the Automated GOLE topology.
If we cannot even provide a connection service on an existing network, then we have no connection service.
Jeroen. <VLAN Planes.pptx>
Dear Jerry and Jeroen, Having seen a lot of arguments going back and forth I do also believe we are making progress. I believe the discussion may be helped if the topics discussed are put into a framework that tries to separate the conceptual descriptions of what NSI is about from the logical (VLAN's, ports, etc.) and physical (technology) issues. I believe both are important to discuss. I know for example a framework (the Integrated Architectural Framework or IAR) that understands 4 levels of abstraction: The "why" level: provides the context in which a system work The "what" level: describes the functionality and concepts The "how" level: describes how things work logicaly The "with what" level: describes the physical element that are needed I believe Jerry is stressing the importance of the "what" level and Jeroen is stressing the importance of the "how" level. Is it an idea to cast the work into a framework like this? My few cents .. Leon. Op 12-12-11 21:25, Jerry Sobieski schreef:
Jeroen - *I* think we are making significant progress on topology. And I believe we *are* converging on solutions that will accommodate all of these needs. This is not a simple issue.
This is a discussion where we are trying to find _/consensus/_. Where there may be several potential solutions to an issue, we try to find a compromise solution where multiple aspects may be accommodated. This is how this group seems to work best, and has made considerable and successful progress in that fashion.
I know hashing through this stuff is slow and painful, but the results have been good... It gets everyone on the same page and gets everyone to agree...which, for a *standard*, is crucial. So please don't get frustrated or annoyed - we need to work through these issues and find that compromise. We are close.
I do not think a vote will resolve the issues.
Jerry
On 12/12/11 3:27 AM, Jeroen van der Ham wrote:
Hello,
I have the feeling this discussion is not going anywhere. We have been trading arguments for a couple of months now, and neither side seems to be moving. I have the feeling that it may be better to put this to the vote.
Jeroen.
On 11 Dec 2011, at 23:09, Jerry Sobieski wrote:
Hey Jeroen - I will try to make my discussion more succinct:-)
On 12/11/11 12:36 PM, Jeroen van der Ham wrote:
Hi,
Jerry, please make shorter arguments. I think this is an important discussion, but I cannot dedicate all my time to reading your emails. Your point below could have been made a lot more succinctly.
Mapping different labels and/or layers (VLANs in this case) to different network representations has been studied before.[1] It has the advantage of making pathfinding somewhat simpler, at the cost of generating those representations. There are two problems with it: - it makes the network representation a lot more complex, making it a lot harder to diagnose problems. The topology *is* complex - simplification means topology hiding and delegation. Keep in mind we are not looking for an /optimal /path - we are simply looking for any _/acceptable/_ path, one that meets a set of specific constraints provided by the RA. _/Any/_ path will do as long as it meets those constraints. Thus, we can define network regions and perform the high level interdomain path selection based upon adjacency and segment Reservations. And then go to the NSAs along a candidate path to check the resources and reserve the segments. _/The external inter-domain PF does not need to know the details/_ - we let the local internal NSA (and ultimately the NRM) deal with those. The adaptations and multilayer incompatibilities are expressed in the topology by simple connectivity at a node. You have to do it somewhere. With the proper abstractions and architecture, it all will all come out in the wash.
As for diagnosing "problems" - I am not concerned about large topologies. That is the price of admission. If you mean just debugging a large topology file itself...well, these will be autogenerated with tools or the NSAs themselves, and built up from smaller more local views, so I am not worried about generating correct topology. I am more concerned with insuring the topological model allows large topologies to be practical (!) We need to make sure the algebra of combining smaller more manageable topology files to create larger complex topologies in both scope and detail is provably correct. And that we can hide topology where necessary or desired for scaling, security, etc. - and things still work.
We need NSI to define the canonical form of a "Connection" and "Service Termination Point", the "Network Service" node and a generic NSI Topology model. And let the technology specific aspects be handled by the NRMs or map themselves to NSI constructs. We can leverage principles of object oriented design to define generic topological objects that expose more topologically significant functions while hiding hardware specific details and which present common easily modeled nodal functions for external pathfinders. I look forward to this as it will allow us to encode network nodes that do encapsulation/decapsulation, stacking (virtual layer) functions, switching, muxing/demuxing, etc. To do this, we have to start at the high level (inter-domain) and work our way down to more detailed nodes. Yes, the topology will get bigger - but how big is too big? I dunno - but we have a ways to go before its too large. And at what detail do we stop and say...hmm, lets just define an agent to check feasibility, availability, and allocation for this topological region. At the high level, it works using the NSA as the agent, the any-to-any (A2A) transit function for NSI Networks, and the atomic check-reserve semantic of the CS ReservationRequest.
- you get multiple representations of the same link, which have an inter-dependency. You want to represent that the link can carry 10Gb, yet not all of the VLANs can carry 10Gb at the same time. This is an example of shared resource dependencies. Bandwidth is only one example. Common ethernet per-box VLAN scoping is another example of a resource that is shared across multiple physical links, buffer management is often shared at blade levels rather than a single physical port, Shared Risk Link Groups (SRLG), and even more complex shared resources based on authorization limits is another. So what you point out is true, but it is a much broader issue and not solved by simply dealing with VLANs on a physical port. Even with that one example, one could easily imagine a situation where some VLANs on a port are statically routed to one network, and other vlans on the same physical port go to a different real network. (We did this very thing at the FIA demos in October !). We need a more general approach to resource mapping.
I think the way to represent these shared resources might be to have a "grouping" node that identifies a resource (say bandwidth) that is shared among members of that group. I have been trying to think this through... As we have the NSI Topology defined now, such sharing is magically handled by the NSA, its all done internal to the respective networks.
Best regards! Jerry
Jeroen.
[1]: Path selection in multi-layer networks, Fernando Kuipers, Freek Dijkstra: http://staff.science.uva.nl/~fdijkstr/publications/multilayer-pathselection....
On 11 Dec 2011, at 17:55, Jerry Sobieski wrote:
Hi Jeroen-
See attached slides... (just two simple slides)
My point was that if you cannot ever swap between two particular endpoints (portx/vlan100 and porty/vlan101) then those two particular endpoints should not be advertised as being part a network service that says it can do "any to any" switching - it can't. If you advertise this cross-connect capability (as we do implicitly), then you entice and invite remote agents to take advantage of that capability - one which internally you knew all the time was never possible - ever. That seems dis-ingenuous to me at best, and malicious in some worst case. Why not just advertise 1000 Gbps capability as well? And this actually causes the "exhaustive search" problem.
This does not mean that the remaining flat vlan switching capability is not important and useful. Take StarLight for instance, it had four convergent physical links: JGN,KRL,NL, and ESN. Each with the four VLANs. Even though SL could not swap VLAN IDs in the process of switching VLANs, it could still switch VLANs nontheless. So, A VLAN 100 from JGN could in fact switch to either of the other three destinations KRL/vlan100, NL/vlan100, or ESN/vlan100 but it all cases it retains the same VLAN 100. So a non-swapping switch still provides important conventional forwarding/crossconnect switching capability. As it was, by advertising SL as a single physical Network rather than four separate Network Services we created the problem of 75% of advertised routes were impossible.
So we could have defined four VLAN planes SL80, SL81, SL82, SL83 -> each as a separate NSI Network, and each would have had four adjacencies. And those established and advertised adjacencies (SDPs) will have been mapped apriori to the associated VLANs in both adjacent networks. If the adjacent network is also "VLAN challenged" the dependencies would have already been expressed in their [internal] topology in a similar fashion as well. If those adjacent networks were label swapping, then all four endpoints SL80:PS80, SL81:PS81, etc would have converged on the same NSI Network as they do now...indicating that the adjacent network can route the circuit between STPs with different VLAN IDs.
So in fact, just because a switch or a network cannot do VLAN swapping does not mean it cannot do switching - and there is still important value in this capability. By subdividing the challenged Networks into the appropriate VLAN planes, we express the very topological routing information you want. And it did not require any changes to the PFs in other networks - and it did not actually require knowledge of the particular VLANs labels or any physical technology information.
One last point: The mingling of impossible cross-connects is externally indistinguishable from simple internal resource exhaustion. In terms of asking for a Reservation, if the route is impossible or if there is just not enough bandwidth, we still just get a reject. So the question is: If we run out of resources and some crossconnects become "highly improbable" (but not strictly impossible) should we revoke those advertisements on the same grounds that we don't advertise impossible crossconnects? Possibly...:-) How long time will the "improbable" cross connects remain "improbable"? If a cross connect is highly unlikely (e.g. Someone has reserved all 10 Gbps on a 10G path for 6 months...) is it misleading to continue advertsing it? This is where state updates become important and a grey area comes in...
Hope this helps. Jerry
On 12/10/11 2:16 PM, Jeroen van der Ham wrote:
On 10 Dec 2011, at 20:13, Jeroen van der Ham wrote: >> <tirade> >> With respect to VLAN swapping... Inability to swap VLANs is essentially saying your NSI network cannot cross connect - ever - certain STPs. If you cannot *ever* cross connect certain STPs, there is no service! I might as well advertise STPs that point to bananas - I will never be able crossconnect them either but who cares? Advertising capabilities that can never be met is a Bad Thing. It injects false and misleading topological information - it could be considered malicious(!) Sorry, I'm calling bullshit on that one.
In the Automated GOLE topology we currently have 0 networks that are able to do VLAN swapping. Netherlight does have that capability, but due to how things are connected, it is not available for the Automated GOLE topology.
If we cannot even provide a connection service on an existing network, then we have no connection service.
Jeroen. <VLAN Planes.pptx>
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org//mailman/listinfo/nsi-wg
Hi, On 13 Dec 2011, at 06:50, Leon Gommans wrote:
The "why" level: provides the context in which a system work The "what" level: describes the functionality and concepts The "how" level: describes how things work logicaly The "with what" level: describes the physical element that are needed
I believe Jerry is stressing the importance of the "what" level and Jeroen is stressing the importance of the "how" level.
I think these kinds of frameworks are useful, but I do not feel that I'm stressing the importance of "how". My arguments have focused on the fact that in my opinion labels are a necessary component. Having these labels also have an implication on the "how" level, so I've tried to describe that. I'm not sure whether rehashing the whole discussion is constructive at this point. Jeroen.
Hi Jerry, On 12 Dec 2011, at 21:25, Jerry Sobieski wrote:
I know hashing through this stuff is slow and painful, but the results have been good... It gets everyone on the same page and gets everyone to agree...which, for a *standard*, is crucial. So please don't get frustrated or annoyed - we need to work through these issues and find that compromise. We are close.
I do not think a vote will resolve the issues.
The last few months we've been putting arguments back and forth, both for the models that we have in mind. I've put forward a document which analyses both solutions. There is a fundamental difference between the two, and this fundamental solution does not allow for a compromise, it is an either/or situation. Unless I am mistaken in my analysis in the doc, or above, I see no point in further discussion. Jeroen.
participants (3)
-
Jeroen van der Ham -
Jerry Sobieski -
Leon Gommans