My observations... Without putting words in Tomohiro's mouth, the syntax he describes here does not change the localid as an opaque string. As an opaque string, the local network is free to define that string to be whatever they like. Anything. As I understand his proposal, this opaque localid string is preserved - he simply proposes a syntax to enumerate a set of such strings. His proposal will not change the definition of the STP as a 2-tuple, but it will change the *interpretation* of the protocol field in which such constructs appear. So, the primitives would need to now recognize the SourceSTP field (for instance) as a *set* of one or more STPs rather than a single STP, and be able to parse the field to construct that set accordingly. I think both Tomohiro's string enumeration proposal and Freek's topological group specification have merit and relevance to the topic. But I would assert that there is another approach to consider: a grammar for specifying constraints on the reservation generally, or at least specifically for the Source/Dest STP fields. Think of specifying the constraints in a grammar that matched the topology representation. For instance "select STP where STP.Capacity>9.6Gbps and STP.connectedTo->STP.network="X";" or we could use RDF style semantic assertions ala "? connectedTo X". Given the postings, I think there are two rather separate issues we should discuss: 1) How and where *constraint specifications* need to be enhanced to support more powerful CS primitives, and 2) how to efficiently represent large scale enumerated constructs in the topology. I think first discussion should be: In order to define a "Set" field constraint for SourceSTP and/or DestSTP in a reservation request (or other attributes), how should such a "set" constraint be represented in the primitive message field? a) Should it take the form of a single STP but place syntactic constructs in the localid string meant to enumerate a set of strings, and by doing so, define a protocol "set" of STPs? b) Or would a topological construct that groups STPs be a more appropriate semantic for indicating a particular set of STPs? c) Or should some broader still grammar be conceived that would allow us to apply more sophisticated constraints over a set of STPs to isolate a target [sub]set? d) Or a combination/all of the above? (a) works ok for specific instances where string constructs can indicate a set. It is simple and would be useful where names convey the constraints. But many constraint sets may not be selected by naming convention alone- they might, for instance, be selected by topological adjacency (e.g. "any STP in network Y that is adjacent to network X") (b) implicitly allows us to identify classes of STPs in the topology and would be very useful for relating certain common characteristics topologically - e.g. "these STPs all share the same link capacity", or "these STPs all have the same 802.1Q tag". However, for *constraint specification* this requires that the topology express any/all possible [STP] constraints as a topological object instance...this is arguably hard to anticipate. Topological groupings are (IMO) more useful for describing defacto resource relationships rather than anticipated constraint specifications, but where a topological object does indeed capture a constraint (e.g. "any STP in Network X") using that topological object ought to be semantically allowed. (c) Constraint specification grammar could allow powerful specification "any STPs in network X adjacent to network Y with 10Gbps link capacity" that allows an RA to specify any attribute or value they know about to set the constraints. This also implies a "constraint specification grammar" imbedded in the reservation parameters, but this is not be so difficult - for instance SQL could be used, or a Semantic predicate grammar... d) all are useful for constrained STP matching and other things, and seem to be non-conflicting..., I would suggest they can co-exist. Regards Jerry On 1/4/12 7:13 AM, Freek Dijkstra wrote:

Hi,

...

I am very much against assigning semantics to parts of STP identifiers. I don't follow the discussion as closely as Jeroen, but I must agree with him here.

That is not to say that I dislike the idea of a compact notation that represents a group of labels (such as a group of VLANs). In fact, I think it is a splendid idea.

However, I would recommend to create 1 (one) identifier for this thing, where "this thing" is a resource that specifies a group of labels at a given port. So for example, identifier urn:ogf:network:example.net:2012:su8cnkhfjkshfew8n with type=STP-group and attributes label-type=VLAN and label-range="{1-42,58-63}" or something along these lines. The advantage is that it is possible to later add a VLAN to this group without changing the identifier.

Regards, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg