Hello All, To help move along the debate on STPs, I have prepared the attached document which summarises the current state of discussions on STPs. Could you please take a look and send me your feedback by email or by Skype? I have set up a Skype group on this topic - please let me know if you haven't received an IM and you would like to join. Thanks, Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________
Thanks to Freek Dijkstra and John MacAuley for their feedback. An updated version incorporating their comments is attached. Guy From: Guy Roberts Sent: 09 July 2012 16:31 To: nsi-wg@ogf.org Subject: STPs in NSI v2.0 Hello All, To help move along the debate on STPs, I have prepared the attached document which summarises the current state of discussions on STPs. Could you please take a look and send me your feedback by email or by Skype? I have set up a Skype group on this topic - please let me know if you haven't received an IM and you would like to join. Thanks, Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________
On 09-07-2012 19:26, Guy Roberts wrote:
Hello All,
To help move along the debate on STPs, I have prepared the attached document which summarises the current state of discussions on STPs. Could you please take a look and send me your feedback by email or by Skype?
Hi, Attached are a couple of examples with what I think is slightly better syntax. In my opinion it eliminates some of the quirkiness of the current unidirectional/bidirectional constructs. Basically every endpoint is an STP, which can have a source, a sink or both. The result is that you can easily define bidirectional path requests, unidirectional path requests, multipoint-to-multipoint path requests, and point-to-multipoint path requests. I heard some critique about the query part in URNs. Hence, I put the VLAN specification in a XML subelement, and gave some example where it is included or not. I have no preference for either the vlans in the URN or in some other XML construct, but will ask Jeroen when he returns from holiday (he may have some more intelligent remarks than I do). It tries to be a bit generic about the label type, so it can be used for other labels than a VLAN, e.g. an I-SID. (One open question if we want to make it explicit that this is the C-VLAN ID, rather than the S-VLAN ID). Regards, Freek
On Tue, 10 Jul 2012, Freek Dijkstra wrote:
Attached are a couple of examples with what I think is slightly better syntax.
Thanks for providing these. They clear up a lot on how the whole thing is supposed to go together with topology in general.
In my opinion it eliminates some of the quirkiness of the current unidirectional/bidirectional constructs. Basically every endpoint is an STP, which can have a source, a sink or both. The result is that you can easily define bidirectional path requests, unidirectional path requests, multipoint-to-multipoint path requests, and point-to-multipoint path requests.
I think I like this. It took a bit of time for the sink concept to sink in (pun very much intended). The switch suggestion (I forgot who came up with it, sorry) also has its merits, but it is tricky for me to see full implications of each. Setting up the multipoint link will be interesting, but rejecting them is always an option.
I heard some critique about the query part in URNs. Hence, I put the VLAN specification in a XML subelement, and gave some example where it is included or not.
I'm not really sure either. In some aspect VLAN is part of the data we move around so it shouldn't really be touched, however they are so used that it is something we have to support with the quirks that come with it. What I like most about the suggestion is that it is now fairly concrete, well-specified and integrated into NSI. Something we haven't really had before. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On 11-07-2012 11:09, Henrik Thostrup Jensen wrote:
In some aspect VLAN is part of the data we move around so it shouldn't really be touched, however they are so used that it is something we have to support with the quirks that come with it.
I disagree, to me the VLAN is part of the header, not of the data stream. I presume that the actual end-user submits his/hers data to the network without VLAN, even though by the time it reaches the first STP the network provider will likely added a VLAN to the data. Would it be useful to distinguish between a C-VLAN (which I consider part of the data stream) and the S-VLAN and/or I-SID (which I consider part of the ISP headers)? (and you may now point me at the fact that I mixed C-VLAN and S-VLAN in my previous message, oops.) Perhaps more important: I presume most STP will be a 802.1Q Ethernet interface, thus with VLAN tags. Would NSI also support a STP without VLAN tags? Freek
Hi Freek, On 07/11/2012 11:30 AM, Freek Dijkstra wrote:
I disagree, to me the VLAN is part of the header, not of the data stream. I presume that the actual end-user submits his/hers data to the network without VLAN, even though by the time it reaches the first STP the network provider will likely added a VLAN to the data.
As an end-user, I can tell you we have a differing view here: one of the things that makes NSI attractive to us is having the ability to aggregate multiple lightpaths on each 10G link between us and our NREN, by using VLAN tags. So I am assuming that the traffic leaves/arrives tagged at the end user. Please also take note of how SURFnet intends to use 'Multi Service Ports' in the SURFnet-7 that is currently being rolled out. Regards, Paul Boven. -- Paul Boven <boven@jive.nl> +31 (0)521-596547 Unix/Linux/Networking specialist Joint Institute for VLBI in Europe - www.jive.nl VLBI - It's a fringe science
On 11-07-2012 11:40, Paul Boven wrote:
Hi Freek,
On 07/11/2012 11:30 AM, Freek Dijkstra wrote:
I disagree, to me the VLAN is part of the header, not of the data stream. I presume that the actual end-user submits his/hers data to the network without VLAN, even though by the time it reaches the first STP the network provider will likely added a VLAN to the data.
As an end-user, I can tell you we have a differing view here: one of the things that makes NSI attractive to us is having the ability to aggregate multiple lightpaths on each 10G link between us and our NREN, by using VLAN tags. So I am assuming that the traffic leaves/arrives tagged at the end user. Please also take note of how SURFnet intends to use 'Multi Service Ports' in the SURFnet-7 that is currently being rolled out.
For clarification: I was not implying that you MUST NOT use VLAN tags at the end-site. In fact, I am well aware of your setup, and how useful this ability is. What I was commenting on is if the VLAN ID may or may not be changed along the way. For example, I have some connection with NORDUnet which they tag as VPLS 1000, and arrives with C-VLAN ID 1000 at Netherlight. Since that VLAN is already is use with SARA, NetherLight retags it to VLAN 2001. I combined Henriks comment that the "VLAN [ID] is part of the data [stream]" with my personal mantra "don't alter the customers data stream" as to read "don't ever change the VLAN ID", and I disagreed with that. Hope this clarifies things. What do you think, may a NSI network alter the VLAN ID ("swap label") along the way? Freek
On Wed, 11 Jul 2012, Freek Dijkstra wrote:
On 11-07-2012 11:09, Henrik Thostrup Jensen wrote:
In some aspect VLAN is part of the data we move around so it shouldn't really be touched, however they are so used that it is something we have to support with the quirks that come with it.
I disagree, to me the VLAN is part of the header, not of the data stream. I presume that the actual end-user submits his/hers data to the network without VLAN, even though by the time it reaches the first STP the network provider will likely added a VLAN to the data.
This is all a matter of perspective, and what the user wants. I don't see there being any right or wrong. Jerry have though a lot about what to do with framing and so, so I'll let him fill out the details here :-).
Would it be useful to distinguish between a C-VLAN (which I consider part of the data stream) and the S-VLAN and/or I-SID (which I consider part of the ISP headers)? (and you may now point me at the fact that I mixed C-VLAN and S-VLAN in my previous message, oops.)
I don't know. But we need to have some semantics about framing and what will happen with it.
Perhaps more important: I presume most STP will be a 802.1Q Ethernet interface, thus with VLAN tags.
It is likely. I don't know. I'd suppose regular untagged ethernet and IP being rather common as well. I still think the whole ethernet/VLAN interface is silly. The first thing users (and ourselves) do is to put IP on top of it. A "good" user interface towards NSI will ask for the IPs you'll want the bandwidth between and bandwidth in each direction, and then figure out the rest. Of course this should not be the base abstraction in NSI, but something that can be built on top of what we have.
Would NSI also support a STP without VLAN tags?
Most definitely yes (IMHO). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (4)
-
Freek Dijkstra -
Guy Roberts -
Henrik Thostrup Jensen -
Paul Boven