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.