[Nsi-wg] STP

[Jerry Sobieski]

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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg