[Nsi-wg] Cannot specify range of VLAN identifiers in EVTS service

[Hans Trompert]

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.