25 Jan
2010
25 Jan
'10
3:38 p.m.
Crystal clear :)
Agreed.
Regards,
--
Joan A. García-Espín
CTX, i2CAT Foundation
El 25/01/2010, a las 15:14, Jerry Sobieski escribió:
> 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@ogf.org
>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg@ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>