Hi all- Things have been very disorganized the last few weeks regarding the demos. I have been distracted on some other issues and am sorry about this. But this is the situation: The NSI version2 implementations are not all ready. And some key GOLEs will only have V1 available, or will not be able to perform aggregation functions,... and the status monitors will also need to be able to deal with two versions... And no doubt there will be some technical issues we'll need to iron out as we implement and test... so I think a comprehensive NSIv2 over the Automated GOLE fabric is going to have to be re-thought... I think it is just not realistic to have the AutomatedGOLE running V2 everywhere, and even more unlikely we would be able to have them both *interoperating* at this time. However... all is not lost... We should keep in mind that what we want to demonstrate and promote at SC is *_/*NSI*/__/*and [automated] GOLEs*/_* - not specifically v2 per se, although it would be nice. But our priority should be to demonstrate and promote a _/global NSI as the ubiquitous protocol/_...with many implementations, and its features where they are ready. Remember, many of the folks at SC have only just heard of NSI and need basic high level vision, status, and roadmap - not details about state machines or topologies, or even I suspect will they need to see a Modify() primitive actually work:-) Besides, the differences between v1 and v2 are largely internal advances and do not much present new capabilities to the end user. So if we keep this Big Picture perspective for SC12, I think we can still have a very powerful NSI + AutoGOLE demonstration despite the varying degrees of readiness for v2... ---> NSI as the common ubiquitous automated provisioning framework/protocol, and ---> Open Lightpath Exchanges (and "distributed" exchanges) as the emerging global transport architecture, ---> And the AutomatedGOLE Fabric running NSI is an existence proof and test facility for early adopters. So I would like to propose we take the following tact for SC: - We leverage the NSI "service definition" concept.. We define "ets" services as v1, and we define a new set of service domains called "etsv2". - We preserve the AutoGOLE running NSIv1 as-is using vlans 1780-1783. THis will allow us to show NSI running using the status displays we have already working. - We establish a second "etsv2" service plane consisting of NSIv2 domains - these will get VLANs 1790-1799. - Even if the ETS and ETSv2 domains cannot interoperate at the protocol layer, they can still interconnect at the data plane layer. One domain would simply be the "static" client of another... For instance, we can have the ETSv2 domains act as end systems on the edge of a ETS (v1) domain, and we set up vlans across v1 to serve the v2 domain SDPs. THis is a tunneled strategy, but it would be interesting to show the capability none-the-less. THis would then allow both V1 and V2 provisioning demos to occur simultaneously. - or We could also/instead simply manually configure the 1790-99 VLANs across the AutoGOLE between the V2 domains. THis would also allow both V1 and V2 provisioning demos to occur simultaneously. - We define the topologies accordingly. This would allow us to have both versions running in parallel, even if they do not interoperate at the control plane. And frankly, its a good migration strategy to v2 in the AutoGOLE rather than a flag day. This allows those implementations that have v2 to demonstrate v2 albeit in a somewhat constrained manner... But We can still explain the development status and roadmap for the next several quarters. And we can still present the NSI capabilities and vision and active Workging Group... If the current Huricane sitting on top of me does not take me off the air, I will try to put a couple slides out to the lists to diagramtically explain this... Thoughts? Best regards Jerry
in addition to vlan ids 1780-1783 & 1796-1799, vlan ids 1790-1795 are also now reserved in SCinet for automated-GOLE demos. Alan On Mon, 29 Oct 2012, Jerry Sobieski wrote:
Hi all-
Things have been very disorganized the last few weeks regarding the demos. I have been distracted on some other issues and am sorry about this. But this is the situation:
The NSI version2 implementations are not all ready. And some key GOLEs will only have V1 available, or will not be able to perform aggregation functions,... and the status monitors will also need to be able to deal with two versions... And no doubt there will be some technical issues we'll need to iron out as we implement and test... so I think a comprehensive NSIv2 over the Automated GOLE fabric is going to have to be re-thought...
I think it is just not realistic to have the AutomatedGOLE running V2 everywhere, and even more unlikely we would be able to have them both *interoperating* at this time.
However... all is not lost...
We should keep in mind that what we want to demonstrate and promote at SC is *_/*NSI*/__/*and [automated] GOLEs*/_* - not specifically v2 per se, although it would be nice. But our priority should be to demonstrate and promote a _/global NSI as the ubiquitous protocol/_...with many implementations, and its features where they are ready. Remember, many of the folks at SC have only just heard of NSI and need basic high level vision, status, and roadmap - not details about state machines or topologies, or even I suspect will they need to see a Modify() primitive actually work:-) Besides, the differences between v1 and v2 are largely internal advances and do not much present new capabilities to the end user.
So if we keep this Big Picture perspective for SC12, I think we can still have a very powerful NSI + AutoGOLE demonstration despite the varying degrees of readiness for v2... ---> NSI as the common ubiquitous automated provisioning framework/protocol, and ---> Open Lightpath Exchanges (and "distributed" exchanges) as the emerging global transport architecture, ---> And the AutomatedGOLE Fabric running NSI is an existence proof and test facility for early adopters.
So I would like to propose we take the following tact for SC:
- We leverage the NSI "service definition" concept.. We define "ets" services as v1, and we define a new set of service domains called "etsv2".
- We preserve the AutoGOLE running NSIv1 as-is using vlans 1780-1783. THis will allow us to show NSI running using the status displays we have already working.
- We establish a second "etsv2" service plane consisting of NSIv2 domains - these will get VLANs 1790-1799.
- Even if the ETS and ETSv2 domains cannot interoperate at the protocol layer, they can still interconnect at the data plane layer. One domain would simply be the "static" client of another... For instance, we can have the ETSv2 domains act as end systems on the edge of a ETS (v1) domain, and we set up vlans across v1 to serve the v2 domain SDPs. THis is a tunneled strategy, but it would be interesting to show the capability none-the-less. THis would then allow both V1 and V2 provisioning demos to occur simultaneously.
- or We could also/instead simply manually configure the 1790-99 VLANs across the AutoGOLE between the V2 domains. THis would also allow both V1 and V2 provisioning demos to occur simultaneously.
- We define the topologies accordingly.
This would allow us to have both versions running in parallel, even if they do not interoperate at the control plane. And frankly, its a good migration strategy to v2 in the AutoGOLE rather than a flag day. This allows those implementations that have v2 to demonstrate v2 albeit in a somewhat constrained manner... But We can still explain the development status and roadmap for the next several quarters. And we can still present the NSI capabilities and vision and active Workging Group...
If the current Huricane sitting on top of me does not take me off the air, I will try to put a couple slides out to the lists to diagramtically explain this...
Thoughts?
Best regards Jerry
Hi Alan, PSNC requested VLAN 1780 to be setup from PSNC through NetherLight and MANLAN towards their booth at SC'12. At MANLAN and SCinet this particular VLAN 1780 will be configured statically (amongst the Dutch SC'12 VLANs on the AMS-NYC OC-192). Best regards, Gerben On 30-10-2012 03:38, Alan Verlo wrote:
in addition to vlan ids 1780-1783 & 1796-1799, vlan ids 1790-1795 are also now reserved in SCinet for automated-GOLE demos.
Alan
On Mon, 29 Oct 2012, Jerry Sobieski wrote:
Hi all-
Things have been very disorganized the last few weeks regarding the demos. I have been distracted on some other issues and am sorry about this. But this is the situation:
The NSI version2 implementations are not all ready. And some key GOLEs will only have V1 available, or will not be able to perform aggregation functions,... and the status monitors will also need to be able to deal with two versions... And no doubt there will be some technical issues we'll need to iron out as we implement and test... so I think a comprehensive NSIv2 over the Automated GOLE fabric is going to have to be re-thought...
I think it is just not realistic to have the AutomatedGOLE running V2 everywhere, and even more unlikely we would be able to have them both *interoperating* at this time.
However... all is not lost...
We should keep in mind that what we want to demonstrate and promote at SC is *_/*NSI*/__/*and [automated] GOLEs*/_* - not specifically v2 per se, although it would be nice. But our priority should be to demonstrate and promote a _/global NSI as the ubiquitous protocol/_...with many implementations, and its features where they are ready. Remember, many of the folks at SC have only just heard of NSI and need basic high level vision, status, and roadmap - not details about state machines or topologies, or even I suspect will they need to see a Modify() primitive actually work:-) Besides, the differences between v1 and v2 are largely internal advances and do not much present new capabilities to the end user.
So if we keep this Big Picture perspective for SC12, I think we can still have a very powerful NSI + AutoGOLE demonstration despite the varying degrees of readiness for v2... ---> NSI as the common ubiquitous automated provisioning framework/protocol, and ---> Open Lightpath Exchanges (and "distributed" exchanges) as the emerging global transport architecture, ---> And the AutomatedGOLE Fabric running NSI is an existence proof and test facility for early adopters.
So I would like to propose we take the following tact for SC:
- We leverage the NSI "service definition" concept.. We define "ets" services as v1, and we define a new set of service domains called "etsv2".
- We preserve the AutoGOLE running NSIv1 as-is using vlans 1780-1783. THis will allow us to show NSI running using the status displays we have already working.
- We establish a second "etsv2" service plane consisting of NSIv2 domains - these will get VLANs 1790-1799.
- Even if the ETS and ETSv2 domains cannot interoperate at the protocol layer, they can still interconnect at the data plane layer. One domain would simply be the "static" client of another... For instance, we can have the ETSv2 domains act as end systems on the edge of a ETS (v1) domain, and we set up vlans across v1 to serve the v2 domain SDPs. THis is a tunneled strategy, but it would be interesting to show the capability none-the-less. THis would then allow both V1 and V2 provisioning demos to occur simultaneously.
- or We could also/instead simply manually configure the 1790-99 VLANs across the AutoGOLE between the V2 domains. THis would also allow both V1 and V2 provisioning demos to occur simultaneously.
- We define the topologies accordingly.
This would allow us to have both versions running in parallel, even if they do not interoperate at the control plane. And frankly, its a good migration strategy to v2 in the AutoGOLE rather than a flag day. This allows those implementations that have v2 to demonstrate v2 albeit in a somewhat constrained manner... But We can still explain the development status and roadmap for the next several quarters. And we can still present the NSI capabilities and vision and active Workging Group...
If the current Huricane sitting on top of me does not take me off the air, I will try to put a couple slides out to the lists to diagramtically explain this...
Thoughts?
Best regards Jerry
got it, will do. Alan On Tue, 30 Oct 2012, Gerben van Malenstein wrote:
Hi Alan,
PSNC requested VLAN 1780 to be setup from PSNC through NetherLight and MANLAN towards their booth at SC'12. At MANLAN and SCinet this particular VLAN 1780 will be configured statically (amongst the Dutch SC'12 VLANs on the AMS-NYC OC-192).
Best regards, Gerben
On 30-10-2012 03:38, Alan Verlo wrote:
in addition to vlan ids 1780-1783 & 1796-1799, vlan ids 1790-1795 are also now reserved in SCinet for automated-GOLE demos.
Alan
On Mon, 29 Oct 2012, Jerry Sobieski wrote:
Hi all-
Things have been very disorganized the last few weeks regarding the demos. I have been distracted on some other issues and am sorry about this. But this is the situation:
The NSI version2 implementations are not all ready. And some key GOLEs will only have V1 available, or will not be able to perform aggregation functions,... and the status monitors will also need to be able to deal with two versions... And no doubt there will be some technical issues we'll need to iron out as we implement and test... so I think a comprehensive NSIv2 over the Automated GOLE fabric is going to have to be re-thought...
I think it is just not realistic to have the AutomatedGOLE running V2 everywhere, and even more unlikely we would be able to have them both *interoperating* at this time.
However... all is not lost...
We should keep in mind that what we want to demonstrate and promote at SC is *_/*NSI*/__/*and [automated] GOLEs*/_* - not specifically v2 per se, although it would be nice. But our priority should be to demonstrate and promote a _/global NSI as the ubiquitous protocol/_...with many implementations, and its features where they are ready. Remember, many of the folks at SC have only just heard of NSI and need basic high level vision, status, and roadmap - not details about state machines or topologies, or even I suspect will they need to see a Modify() primitive actually work:-) Besides, the differences between v1 and v2 are largely internal advances and do not much present new capabilities to the end user.
So if we keep this Big Picture perspective for SC12, I think we can still have a very powerful NSI + AutoGOLE demonstration despite the varying degrees of readiness for v2... ---> NSI as the common ubiquitous automated provisioning framework/protocol, and ---> Open Lightpath Exchanges (and "distributed" exchanges) as the emerging global transport architecture, ---> And the AutomatedGOLE Fabric running NSI is an existence proof and test facility for early adopters.
So I would like to propose we take the following tact for SC:
- We leverage the NSI "service definition" concept.. We define "ets" services as v1, and we define a new set of service domains called "etsv2".
- We preserve the AutoGOLE running NSIv1 as-is using vlans 1780-1783. THis will allow us to show NSI running using the status displays we have already working.
- We establish a second "etsv2" service plane consisting of NSIv2 domains - these will get VLANs 1790-1799.
- Even if the ETS and ETSv2 domains cannot interoperate at the protocol layer, they can still interconnect at the data plane layer. One domain would simply be the "static" client of another... For instance, we can have the ETSv2 domains act as end systems on the edge of a ETS (v1) domain, and we set up vlans across v1 to serve the v2 domain SDPs. THis is a tunneled strategy, but it would be interesting to show the capability none-the-less. THis would then allow both V1 and V2 provisioning demos to occur simultaneously.
- or We could also/instead simply manually configure the 1790-99 VLANs across the AutoGOLE between the V2 domains. THis would also allow both V1 and V2 provisioning demos to occur simultaneously.
- We define the topologies accordingly.
This would allow us to have both versions running in parallel, even if they do not interoperate at the control plane. And frankly, its a good migration strategy to v2 in the AutoGOLE rather than a flag day. This allows those implementations that have v2 to demonstrate v2 albeit in a somewhat constrained manner... But We can still explain the development status and roadmap for the next several quarters. And we can still present the NSI capabilities and vision and active Workging Group...
If the current Huricane sitting on top of me does not take me off the air, I will try to put a couple slides out to the lists to diagramtically explain this...
Thoughts?
Best regards Jerry
participants (3)
-
Alan Verlo -
Gerben van Malenstein -
Jerry Sobieski