shared vlans

[Ezra Kissel]

I have been experimenting with shared VLAN support on the BBN EG and IG
racks. In the IG advertisement, I see all the vtsXXXX shared-vlan
options. I pick one of those when specifying shared_vlan_links across
two rspecs, create a couple slivers, and two nodes from different slices
can talk. However, not all IG sites have these vts shared vlans, some
just have the openflow/mesoscale entries. Is it possible to make this
consistent across all IG racks? btw, what does vts stand for?

For EG, I don't see any shared vlans advertised, but I looked at the
bbnvmsite RDF and see 1750, 1755, 1759, etc. which I believe are the
GENI mesoscale shared VLANs. I tried both 1750 and 1759 but neither
allowed two nodes in different slices to talk. Rspecs attached.

Is there something else I should be using in the EG case, maybe another
range of shared vlans that are not advertised?

One other thing I noticed: I initially had an erroneous '/' at the end
of the shared-vlan xmlns. When submitting those rspecs to EG, the link
gets a vlantag set to some incrementing value...2,3, etc. for each
submitted rspec. In the IG case, you get an "inconsistent ifacemap;
..." error. In both case, it would be nice to have an exception if the
xmlns is unrecognized instead so it's easier to identify and fix the
problem. Not sure how hard that would be to add...

thanks,
- ezra

[Jonathon Duerig]

I do not know exactly what the 'vts*' shared-vlans were created for. The
mesoscale shared vlans are intended to be consistent across many racks.
The 'vts*' ones are not.

Detecting an erroneous XML namespace is very tricky. They are in essence
arbitrary labels, and are an unbounded set. There is no easy way of
telling 'the thing I am looking for isn't there' from 'it is there, but in
a slightly wrong namespace'.

---
Broad audience or deep message: Pick one.

> --
> GENI Users is a community supported mailing list, so please help by
> responding to questions you know the answer to.
>
> If this is your first time posting a question to this list, please review
> http://groups.geni.net/geni/wiki/GENIExperimenter/CommunityMailingList
> --- You received this message because you are subscribed to the Google Groups
> "GENI Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to geni-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Nicholas Bastin]

On Thu, May 8, 2014 at 1:21 PM, Ezra Kissel <ezki...@indiana.edu> wrote:

I have been experimenting with shared VLAN support on the BBN EG and IG racks.  In the IG advertisement, I see all the vtsXXXX shared-vlan options.  I pick one of those when specifying shared_vlan_links across two rspecs, create a couple slivers, and two nodes from different slices can talk.  However, not all IG sites have these vts shared vlans, some just have the openflow/mesoscale entries.  Is it possible to make this consistent across all IG racks?  btw, what does vts stand for?

Please do not take the VTS vlans, these are not public resources (at the moment there's nothing we can do to stop you, but you will break other people's experiments).

--

Nick 

[Ezra Kissel]

On 5/8/2014 1:35 PM, Nicholas Bastin wrote:
> On Thu, May 8, 2014 at 1:21 PM, Ezra Kissel <ezki...@indiana.edu

> <mailto:ezki...@indiana.edu>> wrote:
>
> I have been experimenting with shared VLAN support on the BBN EG and
> IG racks. In the IG advertisement, I see all the vtsXXXX
> shared-vlan options. I pick one of those when specifying
> shared_vlan_links across two rspecs, create a couple slivers, and
> two nodes from different slices can talk. However, not all IG sites
> have these vts shared vlans, some just have the openflow/mesoscale
> entries. Is it possible to make this consistent across all IG
> racks? btw, what does vts stand for?
>
>

> Please do not take the VTS vlans, these are not public resources (at the
> moment there's nothing we can do to stop you, but you will break other
> people's experiments).
>

Ah, so virtual topology service, now I put it together. :) I'll leave
them alone then. So really there are just the mesoscale VLANs that
provide common-tagged interfaces for experimenters?

[Nicholas Bastin]

On Thu, May 8, 2014 at 1:38 PM, Ezra Kissel <ezki...@indiana.edu> wrote:

Ah, so virtual topology service, now I put it together. :)  I'll leave them alone then.  So really there are just the mesoscale VLANs that provide common-tagged interfaces for experimenters?

Well, you can make yourself new shared VLANs - the ones in the ad are just the ones that already exist.

There are some intricacies to making shared VLANs, but you can do this as an experimenter if that's what you really want.  The general process is:

* Make a sliver at a (IG) rack that causes a VLAN to get provisioned to your sliver (I can show you how to "trick" it into doing this, or there's some example code in geni-lib that does this)

* Perform an operational action on your sliver that shares the VLAN in question

* Now your shared VLAN will show up in the ad and you can make new slivers that connect to it

 - (If you ever delete the first sliver, the shared VLAN will go away)

--

Nick

[Ezra Kissel]

On 5/8/2014 1:41 PM, Nicholas Bastin wrote:

> Well, you can make yourself new shared VLANs - the ones in the ad are
> just the ones that already exist.
>
> There are some intricacies to making shared VLANs, but you can do this
> as an experimenter if that's what you really want. The general process is:
>
> * Make a sliver at a (IG) rack that causes a VLAN to get provisioned to
> your sliver (I can show you how to "trick" it into doing this, or
> there's some example code in geni-lib that does this)
>
> * Perform an operational action on your sliver that shares the VLAN in
> question
>
> * Now your shared VLAN will show up in the ad and you can make new
> slivers that connect to it
> - (If you ever delete the first sliver, the shared VLAN will go away)
>
> --

Yes, that's exactly what I want. I've been trying to find examples, or
any mention of this, but I must be looking in the wrong places...

Should I just look in geni-lib or is there another resource for creating
new shared vlans? I guess I'm concerned about finding a vlan that is
free at a given aggregate...simply trial and error?

thanks,
- ezra

[Jonathon Duerig]

You shouldn't need to pick vlan numbers by hand. That is only important
when doing something like the mesoscale where the same vlan needs to span
multiple sites. Each shared VLAN you create will be local just to that
rack.

---
Broad audience or deep message: Pick one.


On Thu, 8 May 2014, Ezra Kissel wrote:

[Nicholas Bastin]

On Thu, May 8, 2014 at 1:44 PM, Ezra Kissel <ezki...@indiana.edu> wrote:

Yes, that's exactly what I want.  I've been trying to find examples, or any mention of this, but I must be looking in the wrong places...

I don't think there's any examples.

 

Should I just look in geni-lib or is there another resource for creating new shared vlans?  I guess I'm concerned about finding a vlan that is free at a given aggregate...simply trial and error?

You don't have to worry about finding a free VLAN tag, at least, the AM will find that for you.  As a general rule none of the shared vlans advertised by the AM are "free" - they're all being used for a specific purpose.  Now, as it turns out, the "mesoscale" VLANs are being used for the specific purpose of "sharing an OpenFlow network", but in general the shared VLANs are not available if you don't already know what they're for (and have buy-in from the person that created them).

I'll write something up about how to do this at an IG rack and send it along.

--

Nick

[Ezra Kissel]

On 5/8/2014 1:48 PM, Nicholas Bastin wrote:

> On Thu, May 8, 2014 at 1:44 PM, Ezra Kissel <ezki...@indiana.edu
> <mailto:ezki...@indiana.edu>> wrote:
>
> Yes, that's exactly what I want. I've been trying to find examples,
> or any mention of this, but I must be looking in the wrong places...
>
>

> I don't think there's any examples.
>

> Should I just look in geni-lib or is there another resource for
> creating new shared vlans? I guess I'm concerned about finding a
> vlan that is free at a given aggregate...simply trial and error?
>
>

> You don't have to worry about finding a free VLAN tag, at least, the AM
> will find that for you. As a general rule none of the shared vlans
> advertised by the AM are "free" - they're all being used for a specific
> purpose. Now, as it turns out, the "mesoscale" VLANs are being used for
> the specific purpose of "sharing an OpenFlow network", but in general
> the shared VLANs are not available if you don't already know what
> they're for (and have buy-in from the person that created them).
>
> I'll write something up about how to do this at an IG rack and send it
> along.
>

Perfect, thanks. So the AM will pick one for you, that's what I was
wondering. The alternative was to pick one (not already listed in the
ad) and hope no one else is picking the same one. I initially tried
that by specifying an arbitrary vlantag in the shared-vlan element, but
obviously that didn't work.

[Ezra Kissel]

On 5/8/2014 1:27 PM, Jonathon Duerig wrote:
> I do not know exactly what the 'vts*' shared-vlans were created for. The
> mesoscale shared vlans are intended to be consistent across many racks.
> The 'vts*' ones are not.
>
> Detecting an erroneous XML namespace is very tricky. They are in essence
> arbitrary labels, and are an unbounded set. There is no easy way of
> telling 'the thing I am looking for isn't there' from 'it is there, but in
> a slightly wrong namespace'.
>

Yes, good point. The different behavior between AMs is what is really
confusing, because it's hard to tell if it was really parsed or not.
Anyway, I guess most users aren't editing RSpecs by hand, or are at
least better copy-pasters than I am...

[Leigh Stoller]

> Perfect, thanks. So the AM will pick one for you, that's what I was
> wondering. The alternative was to pick one (not already listed in the ad)
> and hope no one else is picking the same one. I initially tried that by
> specifying an arbitrary vlantag in the shared-vlan element, but obviously
> that didn't work.

There *is* a way to specify the vlan tag, but in general we like
to know why before you have our blessing to do it.

Thanks!
Leigh

[Nicholas Bastin]

On Thu, May 8, 2014 at 1:48 PM, Nicholas Bastin <nick....@gmail.com> wrote:

On Thu, May 8, 2014 at 1:44 PM, Ezra Kissel <ezki...@indiana.edu> wrote:

Yes, that's exactly what I want.  I've been trying to find examples, or any mention of this, but I must be looking in the wrong places...

I don't think there's any examples.

As it turns out (thanks to Sarah for pointing this out), there is some documentation at:

http://groups.geni.net/geni/wiki/HowTo/ShareALan

I'm going to work on tweaking it a bit and adding some images to hopefully make it more clear, but it has the information you ultimately need.

--

Nick 

[Leigh Stoller]

> As it turns out (thanks to Sarah for pointing this out), there is some documentation at:
>
> http://groups.geni.net/geni/wiki/HowTo/ShareALan
>
> I'm going to work on tweaking it a bit and adding some images to hopefully make it more clear, but it has the information you ultimately need.

Ah, nice page, thanks Sarah. Ezra, take special note of Caveat #3 ...

Leigh

[Ezra Kissel]

On 5/8/2014 2:04 PM, Leigh Stoller wrote:
>> As it turns out (thanks to Sarah for pointing this out), there is some documentation at:
>>
>> http://groups.geni.net/geni/wiki/HowTo/ShareALan
>>
>> I'm going to work on tweaking it a bit and adding some images to hopefully make it more clear, but it has the information you ultimately need.
>

> Ah, nice page, thanks Sarah. Ezra, take special note of Caveat #3 ...
>
> Leigh
>

Ok - this is great, thanks for the quick responses. This thread came
out of a discussion I had with Niky earlier this week. We were
contemplating having the IDMS shakedown experiment run as a persistent
service on GENI racks and have it configured with shared vlans so other
users could attach to the "service slice" and make use of it. What
would be ideal is to create a common shared vlan at a number of
geographically distributed racks that would then be advertised,
providing a consistent AM:vlantag for experimenters. With the IDMS
slice being long-lived, those shared vlans should persist.

Would something like I just described be possible? We choose a "free"
vlan id at some number of racks, I bring up IDMS slices at those racks
and keep the shared vlan active?

- ezra

[Leigh Stoller]

> Would something like I just described be possible? We choose a "free"
> vlan id at some number of racks, I bring up IDMS slices at those racks
> and keep the shared vlan active?

This is a harder question. Most of the racks with this capability have only
a small number of vlans available for stitching, and so tying one up for a
long time is something that needs to be worked out with the Powers That Be.

Others on this list can say more.

Leigh

[Ezra Kissel]

On 5/8/2014 2:19 PM, Leigh Stoller wrote:
>> Would something like I just described be possible? We choose a "free"
>> vlan id at some number of racks, I bring up IDMS slices at those racks
>> and keep the shared vlan active?
>

> This is a harder question. Most of the racks with this capability have only
> a small number of vlans available for stitching, and so tying one up for a
> long time is something that needs to be worked out with the Powers That Be.
>
> Others on this list can say more.
>

Right, that could be tricky. At the same time, the shared vlans I'm
proposing would all be "local", in the sense that another user who wants
to attach would create their resources on the same rack and have that
tagged traffic visible to one or more nodes in their sliver. They
wouldn't necessarily have to stitch into that vlan. I assume there's a
distinction between those vlan ids advertised for stitching and the
vlans that could be created on the switch for local tagged traffic
between rack nodes/VMs?

But that raises another question for a long-lived service experiment
like IDMS that will need to have active stitched slivers to form an
adequate data plane across racks. For the time being, I can make the
persistent slivers reside on racks with adequate numbers of vlans that
would allow them to be stitched over long periods.

- ezra

[Nicholas Bastin]

On Thu, May 8, 2014 at 2:11 PM, Ezra Kissel <ezki...@indiana.edu> wrote:

Would something like I just described be possible?  We choose a "free" vlan id at some number of racks, I bring up IDMS slices at those racks and keep the shared vlan active?

With at least one possibly significant (MTU-related) caveat, you could use VTS (where available) to provide this kind of service slice without sucking up any additional scarce WAN resources.

This isn't a panacea - VTS only lives at 5 racks right now (and no EG racks), has very limited experimenter-facing docs, and we'd need to spend some time making sure everything worked the way you want (specifically the user experience for how other experiments attach to your slice), but is specifically designed to help facilitate doing these kinds of things.

--

Nick 

[Ezra Kissel]

On 5/8/2014 2:28 PM, Nicholas Bastin wrote:

> On Thu, May 8, 2014 at 2:11 PM, Ezra Kissel <ezki...@indiana.edu
> <mailto:ezki...@indiana.edu>> wrote:
>
> Would something like I just described be possible? We choose a
> "free" vlan id at some number of racks, I bring up IDMS slices at
> those racks and keep the shared vlan active?
>
>

> With at least one possibly significant (MTU-related) caveat, you could
> use VTS (where available) to provide this kind of service slice without
> sucking up any additional scarce WAN resources.
>
> This isn't a panacea - VTS only lives at 5 racks right now (and no EG
> racks), has very limited experimenter-facing docs, and we'd need to
> spend some time making sure everything worked the way you want
> (specifically the user experience for how other experiments attach to
> your slice), but is specifically designed to help facilitate doing these
> kinds of things.
>

I'd like to investigate this, and I think the use case would be pretty
interesting to demonstrate. IDMS over VTS as a GENI service on top of
another GENI service for other experimenters to use. Let me read-up on
VTS and we can probably coordinate off-thread.

thanks,
- ezra

[Nicholas Bastin]

On Thu, May 8, 2014 at 2:47 PM, Ezra Kissel <ezki...@indiana.edu> wrote:

I'd like to investigate this, and I think the use case would be pretty interesting to demonstrate.  IDMS over VTS as a GENI service on top of another GENI service for other experimenters to use.  Let me read-up on VTS and we can probably coordinate off-thread.

There is a collection of not-that-organized and not-that-complete information on VTS at:

https://barnstorm.atlassian.net/wiki/display/VTS/Introduction

Beyond that I'll need to do more writing and direct help, but that's how these things get better.. :-)

--

Nick 

[Niky Riga]

Hi Ezra,

Another option you have available for inter-rack communication is to use  one of the shared multi-point vlans we have already setup in a few places. These are very similar to the mesoscale VLANs they are just non-OF and they  are over AL2S.

The racks that currently have these vlans are:
  * GPO, Utah, NYU, Nysernet, Illinois, Wisconsin, Rutgers (not a production rack yet).

The only thing you have to do is attach your VM to one of these shared VLANs.
The use of these VLANs is currently one VLAN to one experiment.
 If you want you can use vlan: reservedvlan1

One caveat is that there is no MAC learning happening within AL2S so just be a bit careful on the amount of traffic you are sending over those VLANs. The MobilityFirst team and WiMAX sites have been using these VLANs with no problem for the past 6 months.

I think this is probably the quickest way to set up your slice and try it out while you get familiarized with VTS. I do think it is a great idea to try out this composition of services but you shouldn't be blocked on this.

I also think it would be really cool if your slice could use any of the available ways to connect resources:  shared vlans, VTS, stitching.

As for stitching I know that it is a scarce resource in some places, but I think it is also important to gain
experience on people using it and trying to setup services on top of it. I think it is ok if you set up a few stitched links for your service and keep them for a while and we can deal with any shortage problems as they come up.

Cheers,
Niky

Nicholas Bastin

May 8, 2014 at 2:52 PM

I'd like to investigate this, and I think the use case would be pretty interesting to demonstrate.  IDMS over VTS as a GENI service on top of another GENI service for other experimenters to use.  Let me read-up on VTS and we can probably coordinate off-thread.

There is a collection of not-that-organized and not-that-complete information on VTS at:

https://barnstorm.atlassian.net/wiki/display/VTS/Introduction

Beyond that I'll need to do more writing and direct help, but that's how these things get better.. :-)

--

Nick 

--
GENI Users is a community supported mailing list, so please help by responding to questions you know the answer to.
 
If this is your first time posting a question to this list, please review http://groups.geni.net/geni/wiki/GENIExperimenter/CommunityMailingList
---
You received this message because you are subscribed to the Google Groups "GENI Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geni-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ezra Kissel

May 8, 2014 at 2:47 PM

I'd like to investigate this, and I think the use case would be pretty interesting to demonstrate.  IDMS over VTS as a GENI service on top of another GENI service for other experimenters to use.  Let me read-up on VTS and we can probably coordinate off-thread.

thanks,
- ezra

Ezra Kissel

May 8, 2014 at 2:11 PM

Ok - this is great, thanks for the quick responses.  This thread came out of a discussion I had with Niky earlier this week.  We were contemplating having the IDMS shakedown experiment run as a persistent service on GENI racks and have it configured with shared vlans so other users could attach to the "service slice" and make use of it.  What would be ideal is to create a common shared vlan at a number of geographically distributed racks that would then be advertised, providing a consistent AM:vlantag for experimenters.  With the IDMS slice being long-lived, those shared vlans should persist.

Would something like I just described be possible?  We choose a "free" vlan id at some number of racks, I bring up IDMS slices at those racks and keep the shared vlan active?

- ezra

Nicholas Bastin

May 8, 2014 at 2:01 PM

As it turns out (thanks to Sarah for pointing this out), there is some documentation at:

http://groups.geni.net/geni/wiki/HowTo/ShareALan

I'm going to work on tweaking it a bit and adding some images to hopefully make it more clear, but it has the information you ultimately need.

--

Nick 

--
GENI Users is a community supported mailing list, so please help by responding to questions you know the answer to.
 
If this is your first time posting a question to this list, please review http://groups.geni.net/geni/wiki/GENIExperimenter/CommunityMailingList
---
You received this message because you are subscribed to the Google Groups "GENI Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geni-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nicholas Bastin

May 8, 2014 at 1:48 PM

On Thu, May 8, 2014 at 1:44 PM, Ezra Kissel <ezki...@indiana.edu> wrote:

Yes, that's exactly what I want.  I've been trying to find examples, or any mention of this, but I must be looking in the wrong places...

I don't think there's any examples.

 

Should I just look in geni-lib or is there another resource for creating new shared vlans?  I guess I'm concerned about finding a vlan that is free at a given aggregate...simply trial and error?

You don't have to worry about finding a free VLAN tag, at least, the AM will find that for you.  As a general rule none of the shared vlans advertised by the AM are "free" - they're all being used for a specific purpose.  Now, as it turns out, the "mesoscale" VLANs are being used for the specific purpose of "sharing an OpenFlow network", but in general the shared VLANs are not available if you don't already know what they're for (and have buy-in from the person that created them).

I'll write something up about how to do this at an IG rack and send it along.

--

Nick

[Ilya Baldin]

Ezra,

I will check the advertisements. The VLANs you indicated are correct (you can see them here https://wiki.exogeni.net/doku.php?id=public:experimenters:resource_types:start). When you say they don't allow slices to communicate - are you starting your own controller on those vlans?Because without that it won't work. These are meant for OpenFlow experimentation, so you are supposed to get VMs from the rack and then create a slice through FOAM with your controller using one of those vlans.

-ilya

Ilya Baldin
Director, Networking Research and Infrastructure
RENCI/UNC Chapel Hill
http://www.renci.org

> --
> --- IMPORTANT! : All ExoGENI issues should be reported to this list (until further notice)
> --- Please visit ExoGENI wiki before asking questions: http://wiki.exogeni.net
>
> --- All issues/questions will be responded to by ExoGENI Ops team
> --- For issues reported before 12pm EDT (M-F), you should receive a response before 5pm ET same day. For issues reported after 12pm (M-F) you should receive a response before 12PM the next business day. Issues reported Sat and Sun will be responded to by the following Monday 5pm ET.
>
> --- Subscribe to ExoGENI events calendar at http://www.exogeni.net/calendar
> --- You received this message because you are subscribed to the Google Groups "geni-orca-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to geni-orca-use...@googlegroups.com.
> To post to this group, send email to geni-or...@googlegroups.com.
> Visit this group at http://groups.google.com/group/geni-orca-users.

> For more options, visit https://groups.google.com/d/optout.

> <ibp-bbn.xml><ibp-bbn2.xml>

[Ezra Kissel]

Thanks, Ilya. I was confusing the reservedvlans available over AL2S and
the mesoscale vlans, which require OF. The fact that that VLAN range is
often named mesoscale-openflow should have made something click...

Not sure if you followed the geni-users discussion, but is there a
feature in ExoGENI to create a shared vlan on-demand, and have it be
active for the slice lifetime at a rack? This would be local to a given
rack, not for stitching.

When you submit a request rspec for a LAN on EG, I see a vlantag get
assigned in the manifest. Is there a way to make that shared so other
slices could attach?

- ezra

On 5/9/2014 9:28 AM, Ilya Baldin wrote:
> Ezra,
>
> I will check the advertisements. The VLANs you indicated are correct (you can see them here https://wiki.exogeni.net/doku.php?id=public:experimenters:resource_types:start). When you say they don't allow slices to communicate - are you starting your own controller on those vlans?Because without that it won't work. These are meant for OpenFlow experimentation, so you are supposed to get VMs from the rack and then create a slice through FOAM with your controller using one of those vlans.
>
> -ilya
>
> Ilya Baldin
> Director, Networking Research and Infrastructure
> RENCI/UNC Chapel Hill
> http://www.renci.org
>
>
>
> On May 8, 2014, at 1:21 PM, Ezra Kissel <ezki...@indiana.edu> wrote:
>

[Ilya Baldin]

Ezra,

That's currently not part of our service model. We are working on slice stitching that will do this dynamically, but it will be a few months before it is finished.

-ilya

Ilya Baldin
Director, Networking Research and Infrastructure
RENCI/UNC Chapel Hill
http://www.renci.org

On May 9, 2014, at 12:43 PM, Ezra Kissel <ezki...@indiana.edu>

[Ezra Kissel]

Ok - thanks for the info. Slice stitching will be a neat feature to have.

On 5/9/2014 1:02 PM, Ilya Baldin wrote:
> Ezra,
>
> That's currently not part of our service model. We are working on slice stitching that will do this dynamically, but it will be a few months before it is finished.
>

> -ilya
>
> Ilya Baldin
> Director, Networking Research and Infrastructure
> RENCI/UNC Chapel Hill
> http://www.renci.org
>
>
>

> On May 9, 2014, at 12:43 PM, Ezra Kissel <ezki...@indiana.edu>