Cannot specify range of VLAN identifiers in EVTS service
When we moved from using the label field in the STP for specifying VLANs to the explicit VLAN element in the EVTS service element we lost the ability to specify an acceptable range of VLAN identifiers. Does anyone see an issue with this? Thanks, John
On Fri, 6 Sep 2013, John MacAuley wrote:
When we moved from using the label field in the STP for specifying VLANs to the explicit VLAN element in the EVTS service element we lost the ability to specify an acceptable range of VLAN identifiers. Does anyone see an issue with this?
As we do not currently have a way to indiciate which resource are used and not (and I don't having that would be a good idea), this can make it somewhat difficult to create paths when VLANs are sparse. A somewhat related issue. We (and I assume most else) can provide a VPN service with a range of VLANs, e.g., 1000-1100 in a single VPN. And we use this towards some of our customers. I have a somewhat difficult time seeing it being used in NSI, at least for now. That doesn't mean it is not relevant. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On 9/9/13 11:58 AM, Henrik Thostrup Jensen wrote:
On Fri, 6 Sep 2013, John MacAuley wrote:
When we moved from using the label field in the STP for specifying VLANs to the explicit VLAN element in the EVTS service element we lost the ability to specify an acceptable range of VLAN identifiers. Does anyone see an issue with this?
As we do not currently have a way to indiciate which resource are used and not (and I don't having that would be a good idea), this can make it somewhat difficult to create paths when VLANs are sparse.
In many cases the user wants to use a specific VLAN ID on a UNI so in these cases this will not hurt, but in all other cases this will move the problem of selecting a usable VLAN ID to the user (application). It also deprives path finders of the ability to implement some fancy VLAN ID selection algorithm and forces the PCE to just do trial and error for finding suitable VLAN IDs on all peering points. Cheers, HansT.
A somewhat related issue.
We (and I assume most else) can provide a VPN service with a range of VLANs, e.g., 1000-1100 in a single VPN. And we use this towards some of our customers. I have a somewhat difficult time seeing it being used in NSI, at least for now. That doesn't mean it is not relevant.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi On Mon, 9 Sep 2013, Hans Trompert wrote:
In many cases the user wants to use a specific VLAN ID on a UNI so in these cases this will not hurt, but in all other cases this will move the problem of selecting a usable VLAN ID to the user (application).
For user termination points, I do not think this will be a problem (and if so, a small one). However for transit links (as in demarcation points to other networks) links, the VLANs are often a shared resource, where several are already used. Furthermore, only a relatively small range of VLANs might be available on such a link. Having the ability E.g., the ndn-netherlight link, has some already allocated VLANs which are in no way available, and we might restrict NSI links to a small range of VLANs. Having the ability to say "any of those will do" is pretty handy. This of course assume VLAN rewrite capability (but it is 2013).
It also deprives path finders of the ability to implement some fancy VLAN ID selection algorithm and forces the PCE to just do trial and error for finding suitable VLAN IDs on all peering points.
Are you interpreting this as a good or bad thing? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On 9/9/13 3:22 PM, Henrik Thostrup Jensen wrote:
On Mon, 9 Sep 2013, Hans Trompert wrote:
In many cases the user wants to use a specific VLAN ID on a UNI so in these cases this will not hurt, but in all other cases this will move the problem of selecting a usable VLAN ID to the user (application).
For user termination points, I do not think this will be a problem (and if so, a small one).
However for transit links (as in demarcation points to other networks) links, the VLANs are often a shared resource, where several are already used. Furthermore, only a relatively small range of VLANs might be available on such a link. Having the ability
E.g., the ndn-netherlight link, has some already allocated VLANs which are in no way available, and we might restrict NSI links to a small range of VLANs. Having the ability to say "any of those will do" is pretty handy. This of course assume VLAN rewrite capability (but it is 2013).
This is what I meant, on UNIs it is not a problem because most of the time the VLAN ID is pre negotiated so it will map to the correct VLAN in the end users domain, on ENNIs it is a problem because you want to be able to specify a range instead of being forced to iterate one by one over the range.
It also deprives path finders of the ability to implement some fancy VLAN ID selection algorithm and forces the PCE to just do trial and error for finding suitable VLAN IDs on all peering points.
Are you interpreting this as a good or bad thing?
It is a bad thing that path finders cannot specify ranges in a NSI request. Cheers, HansT.
participants (3)
-
Hans Trompert -
Henrik Thostrup Jensen -
John MacAuley