[Nsi-wg] Path Object information/function

[Jerry Sobieski]

Hi Joan- A few notes that may shed light on my thinking on this 
topic...(or not:-)

Ultimately, the PO must allow an agent to link from the list of 
tags/handles/URIs/addresses in the PO to a point in the topology.    The 
identifier in the PO must be one that makes sense to the agent 
referncing the PO for some purpose.   If we use a TE-Address in each 
hop, then that string that specifies each address should be recognized 
by the agents as a TE Address.   If we use URIs, then the agents should 
recognize them as URIs.   In either case, there must be some mechanism 
that takes that hop identifier and associates it with some component of 
the topology.   This mechanism may be a sequence of lookups - ala DNS, 
or ala URI("A") maps to Node="Switch1": Port="port 12":VLAN=2036; 
URI("B") maps to ...,  or it could be a parsable substring in the 
URI,..., etc.     The URI tag is a service level construct, but it must 
relate/link somehow to the topology to which it applies.   The STP  URI 
naming convention and URI->Topo resolution process are service level 
constructs, but the STP itself is a point in the topology where the 
service terminates or transits.

Hope this helps explain my thinking...
Jerry



Joan A. Garcia-Espin wrote:
> Thanks Jerry, it's a thorough description!
>
> Nevertheless, the definition of STPs is not 100% clear to me, and I 
> understand John's concerns regarding this.
> As you described, Jerry, STPs may be understood as "pointers" to the 
> service interface of the entities (NSA) that are in charge of the 
> path. In other words, the URL or Service ID of the NSAs, which in any 
> case belong to the service plane, rather to the transport plane.
> I'm not against this, on the contrary, I agree to have STPs in the PO 
> definition. In this case, the PO shows also a list of service entities 
> along the path.
>
> At this point I wonder if the PO is the service plane equivalent of 
> the ERO on the data/transport plane. Obviously, PO and ERO should not 
> have a 1:1 mapping, since PO (using the sub-pathing feature) allows 
> hiding parts of the service plane to unauthorised requesters.
>
> One more issue, I find the sub-pathing capability specially 
> interesting for security (authorisation) issue (who can/cannot request 
> info about a service along a given NSA, etc.).
>
> @John, what does CTP  (C* Transit Points) stand for? Most probably it 
> comes from the call I missed, sorry about that!
>
> regards,
> -- 
> Joan A. García-Espín
> CTX, i2CAT Foundation
>
>
>
>
>
> El 20/01/2010, a las 21:26, John Vollbrecht escribió:
>
>> This is very good - thank you very much.  Some comments in line --
>> except one here -- I like the name CTP rather than STP.  A major
>> reason is that this is on the transport plane, not the service plane,
>> and calling it service termination seems to me to imply service
>> plane.  I leave this discussion to later as it doesn't affect the meat
>> of the discussion.
>>
>>
>> On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote:
>>
>>> Here are some thoughts on what a "Path Object" (PO) should contain
>>> and/or be able to do...please read thru and think about this and let
>>> me
>>> know your thoughts.
>>>
>>> Jerry
>>>
>>>
>>>
>>> - A Path Object is an ordered list of service transit points (STPs)
>>> through which a connection passes.
>>>
>>> - A Path Object must have at least two STPs: The ingress STP, and the
>>> egress STP.
>>>
>>> - A Path Object should allow a path to be described using "sub-paths"
>>> (i.e. other Path Objects) or pointers/tags that reference other  Path
>>> Objects.
>> - are there existing examples of this or is it a proposal?
>>>
>>> - A Path Object is direction sensitive.  I.e. The path is always
>>> interpreted as beginning at the first STP (the head of the list), and
>>> proceeding towards the last STP (the tail) in the list.   There is no
>>> implication that a path object is reversable (or bidirectional).
>>>
>> does this have to do with pathfinding or is there something more to it?
>>
>>> -  A "fully specified" path identifies the complete set of STPs - in
>>> order - that a connection transits from ingress to egress.
>>>
>> are these STPs for all resources in the path  that are controlled by
>> different NRMs
>>> - A "partially specified" path identifies a subset of STPs - in
>>> order -
>>> that the connection transits - but not necessarily every STP the
>>> connection transits.  THis is a "loose hop" path
>>>
>>> - A partially specified path may contain STPs that are, individually,
>>> only partially specified.  For example, a path may contain a STP
>>> indicating a specific switching element to be transitted, without
>>> specifying the specific port or VLAN id to be used.  This could also
>>> be
>>> generalized to indicate something as general as an particular
>>> network to
>>> be transitted.   Alternatively, the path element may specify a "label
>>> set", i.e. a set of labels or STPs that can are acceptable within the
>>> context of that STP.  THis may be useful for conveying valid VLAN
>>> IDs or
>>> Wavelengths that may be available to path selection functions
>>> downstream
>>> or for end-to-end tagging information.
>>>
>>> Path objects can be used in several ways: First, would be to specify
>>> constraints on a *proposed* path - i.e. must transit this switch, but
>>> port selection has full freedom.  Or must transit this previously
>>> defned
>>> path.  The path objects need wild card masks to indicate these
>>> constraints.   Second use is to define a connect "as built", i.e.
>>> after
>>> the cnnection is full specified and/or in service, a fully specified
>>> detailed Path Object would capture the entire detailed path - end-to-
>>> end
>>> but perhaps not fully exposed.
>>>
>> I agree with this, but perhaps defining what is "required" and what is
>> "allowed" , especially in situations where a connection is made from
>> multiple RMAs in different provider agents.
>>
>>
>>> BNF format:
>>>
>>> <Path_Object>  :=  <Path_Object_Header> <Path_List>
>>>
>>> <Path_List>  := <STP>  ( <Path_Object> | <STP> ) +   |
>>> <Path_Object>+
>>>
>>> Path elements can be STPs or Path Objects.  STPs represent topology
>>> locations, these will likely be something such as:
>>> <domain_identifier><pointID> or <dom><node><port><label><...>.   These
>>> will likely be alphanumeric strings, possibly parsable, or they may be
>>> binary structures...  Likewise with Path Objects - these will likely
>>> be
>>> something like <domain><objectID>.   The key concept however is that
>>> the
>>> Path Object contains two types of elements: service termination points
>>> that refer to points in the topology, and a path object tag that refer
>>> to another strucutre outside the current path object.  So each
>>> elemnt of
>>> the path list must have a type code to say what type of path element
>>> it
>>> is, and then a string to uniquely dentify that object within a local
>>> context, and a length that says how long the object tag is.
>>>
>>
>> So, for something like the chain model where segments A-B-C are
>> included.  Typically provider A gets request, inludes ingress and
>> egress of A in the path and forwards the path in a request to B.  I
>> think the ingress and egress of A need to be either dropped or marked
>> as "not part of the request to B".  I think this might be done
>> explicitly or by implication, but would be good to define.
>>
>> John
>>
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>