[Nsi-wg] Path Object information/function
Inder Monga
imonga at es.net
Wed Jan 27 03:47:34 CST 2010
This is very good discussion, look forward to continuing this tomorrow morning. Some comments inline:
On Jan 26, 2010, at 12:08 PM, John Vollbrecht wrote:
> Jerry - thanks again -- good discussion - we might continue tomorrow on call.
>
> comments in line below --
>
>
> On Jan 26, 2010, at 1:16 PM, Jerry Sobieski wrote:
>
>> Some thoughts/comments in line...
>>
>> John Vollbrecht wrote:
>>>
>>> Hi Jerry -
>>>
>>> Thanks for doing this -- I am guessing it will generate a lot of discussion, but that is good. I have a number of questions and comments on thinking about this.
>>>
>>> 1) I would think that there is a difference in loose hop and strict hop if loose hop is optional and strict hop is not.
>> Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
>
> So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
Since NSI is a cross-domain protocol (NRM manages intra-domain pathfinding and setup), I imagine that the client or a neighboring NSA (using older terminology) in NSI will specify ingress and egress STPs for the domain in case of strict hops. A loose hop will then be when an intervening domain is not specified or if ingress into a domain is specified but egress is not, or any other omission. When the path is fully instantiated, it is possible that the full end-to-end ERO may be accessible by management stations, monitoring services and possibly, the client.
>
>> The latter would mean that if this hop is not available, at some point when the PO is referenced, then an error condition should be raised (the alternative is to ignore the hop). I don't think we need the "required" bit - if the hop is in the PO, it is implied to be required (IMO). The "strict" bit probably would be useful, but we should discuss what it means for a hop that is actually a reference toa subpath object.
> Required might be similar to the first definition above.
>>
>>
>>> 2) I am wondering if strict hop for NSI purposes includes ingress and egress from resources controlled by NRM. NRM is the atomic controller for the resource.
>> Even an opaque topology must still have edge points that interface with the rest of the universe. Those edge egress STPs must be linked to specific ingress STPs on the other side of the link so that connections can be progressed across specific interdomain links. So, a remote domain would reveal its edge STPs that serve me, but maybe not others. I may never see and edge STP on the far side of a transit domain. Whether a domain reveals the ingress and egress STPs in a PO is up to the domain. If it does not, there may be difficulties for interactions with domains further downstream, but it should not affect most things (I think).
>>
> Actually this raises a point I am worrying about -- does a STP exist on both connections that are concatenated, or is a STP the place where they are concatenated?
> I also wonder about how this plays with instantiation and monitoring of a connection on a path. Presumably path is required for these as well as request.
There is a confusion on STP: I feel STPs should represent end-to-end service terminations based on the client's perspective. This recursively carries over within a multi-domain when a NSA/service requestor is a client of another domain. It would make better sense to have STPs that exist on both connections that are concatenated.
>>
>>> 3) For some requests the NRM may not want to be advertised/ known by all other NRMs. Is that possible?
>> I do not think the Path Object should reference the NRM or NSAs at all. The PO references *only* points in the topology to describe a path - nothing more. I am pretty adamant about this because the PO will likely be used for a number of differnet purposes - we don't want it to duplicate information for every possible purpose - information that is best maintained elsewhere...and I think the mapping between an STP and the NSA/NRM is best maintained someplace more authoritative.
> any ideas of where? I think this is an ok answer, but would like to have an alternative if its not there.
The fact that you are identifying the domain/sub-domain within the URI will identify the associated NRM through some lookup mechanism. So indirectly the path object would refer to a NRM?
>>
>> However (:-), it *is* necessary that there be an explicit means within the NSI architecture for STP identifiers (service locations) to be mapped to domains in which they reside, relevant NSAs and/or NRMs, policy, etc. But since this will be done for lots of different reasons, I think it should be an explicitly defined aspect of the architecture and an explicit separate service from the NSI Connection Service.
>>
> ok - as noted above
>> I personally like the notion of a URI style name for STPs and POs. An named object should be of the form //<domain>/<subdomain>... /<name>, ala "//Allen/A" where A is the endpoint name, and everything in front is a domain identifier. This makes the domain obvious and explicit for an STP or PO or other object. There are some still soe open issues on this, but we do need this fundamental mapping from <endpoint name> to <location in global topology> that has to happen somehow.... Also, I think the population and maintanence of the name resolution service must be distributed and automated.
>>
> at least defined. I happen to think that for some deployments it might be fairly small and static and could be just a table in an agent.
>
>>> 4) I would think that a path might be "tentative" vs configured - tentative being a request and possibly including some options and configured being what is reserved/ granted to the requestor. I am also thinking that what is configured might be used directly by GMPLS implementations if GMPLS is supported on all resources. It might also be used in NSI provisioning requests. I wonder if it would look different in those different cases.
>> Here is an example of the different purposes I was referring to. If you have an agent (say some middleware agent) that wants to denote some path as tentative, then that is a function of that agent and we don't care how you implement tht functionality inside your agent. But if the NSI architecture needs to exchange path information between agents, then we need a standard NSI Path Object. Again the purpose of the PO is to describe a *path* not to describe the status or purpose of the path. In your example above, I think you overlay Path Object with Connection Object ...they are not te same.
>>
> AH - what is the difference. I certainly have overlaid them and i have assumed that a path would be used to describe the connection, hence a connection is a set of path objects.
I think connection will have other parameters than just path. Connection will have time of expiry, bandwidth, etc. Path object does not carry information on the connection like capacity, deadlines, policy etc.
>
>> I do see paths being specified in differing degrees of detail. For example, a user may specify a loose PO that has three hops: ingress, intermediate STP, and the egress. However, by the time the connection is provisioned that PO may be substantially larger and more complex as there are now dozens of STPs - some in opaque POs - that go into the "as-built" PO. Here again, whether the PO is strict or loose or a mix does not really affect how we describe the path itself. In this example, the "connection object" may indicate a lot more information about the resources along the path than the PO itself carries.
> This is interesting -- I think Vangelis suggested that Connection add info separately to path, not replace it.
>>
>> I think our PO is close to the ERO of GMPLS - but things like hops pointing to other path objects takes it a bit further. I don't think we should assume or favor any intradomain protocol or architecture. I suggest we focus on what NSI needs to function as a complete architecture, and let specific code implementations handle any protovcol conversion necessary.
> I think that being able to use GMPLS, unless it is a demonstrable burden, is a good goal. It may require using only a subset of the path capabilities somehow, but being able to use it would mean that reservation and implementation could be separated and implementation could be done by existing means. If nothing else it helps to keep us honest.
>>
>>
>>
>>>
>>> 5) Does a path object include a pointer to the agent that could or has authorized it? This seems a crucial question and determines if that info must be provided outside the path via some sort of db. I realize that if it is included it might also have such a db, but it could be searched once, especially in the chain-like implementations of provider agents.
>>>
>> Why would this be crucial to be in the PO? I think you are trying to make the Path Object into a Connection Object which would almost certainly contain considerably more information. A conncetion is typically bidirectional, carries all types of *connection related* parameters including authorization credntials, probably monitoring hooks/pointers, etc. The "Path Object" is just the path. Maybe we should discuss what a "connection object" should be ?...
>
> I am trying to make it a connection object. I guess I don't understand the difference :( Perhaps you could describe the difference ?? Sorry --
>
> John
>
>
>>> -- John
>>>
>>>
>>>
>>> On Jan 25, 2010, at 8:51 AM, Jerry Sobieski wrote:
>>>
>>>> Hi Jeroen-
>>>>
>>>> Hmm... I had always assumed that this would be implicit - that a strict hop PO and Loose hop PO would not really look any different.... But honestly I had not considered whther this was necessary or not. My thought was that whatever agent was using the Path Object would need to check it against the topology anyway - in essence perform a Path Computation between Hop(n) and Hop(n+1). If they are adjacent, this would be an almost zero cost check, and if they were not adjacent, a Path Comp would be needed anyway. I don't know that being explicit relieves any agent from checking adjacency, but there may be some error conditions that are detected if the expectation is explicit in some way. There may be a need to indicate when a hop was/is expected to be adjacent (e.g. a strict hop "as-built" PO that describes a provisioned path after the fact vs a reserved PO that may or may not be strict)
>>>>
>>>> This also brings up the issue of whether the underlying topology can change between when a Path Object is created and when that Path Object is referenced/used. I.e. What happens if a specified hop no longer exists? Or if additional switching points are introduced between say when a reservation is created, and when the connection is provisioned?
>>>>
>>>> I don't think I have a position on the question to making strict vs loose explicit - it might be useful or necessary. Or it may be superfluous. Would we specify each particular hop as strict or loose? Or simply indicate the entire PO as strict or loose? (I'd say hop by hop would be best). Perhaps we allow for a boolean indicator on each hop that says this is "strict hop" to previous hop. If it is not set it could be eiterh loose or strict, but if it *is* set, then the hop must be strict.
>>>>
>>>> Also, as we discuss this, we must formulate what we mean by "adjacent". IMO, adjacent means adjacent in terms of provisioning - i.e. nominally, a switching point that must be re-configured as part of provisioning is a hop that should be presnt in a strict hop PO. If a switching point exists only as part of an underlying tunnel connection, and it is not seen as part of the Path Finding process and not reconfigured as part of a connection's provisioning process, then it is not part of the PO.
>>>>
>>>> For example, a Ethernet link established between Cern and Argonne would be seen as a single link in the topology when allocating Layer2 connections. While there may be lots of switching points that went into setting up that express Etehrnet connection, as far as the Path Finder is concerend, there is one ethernet STP in Cern and one in Argonne, and so provisioning a path between Cern and US over that link would not indicate all those lower layer switching SDH and Wave and Fiber switching points. None of them were reconfigured as part of a connectionusing that long link. However, if a connection is built that adapts the PDU from an Ethernet VLAN into a GFP payload on a sonet link, then that adaptation point is something that is visible to the Path Finder in the topology and is something that is reconfigured to establsih the connection - the Ethernet egress and the GFP ingress STPs are specifically part of the circuit and should be in a strict hop PO. To be complete, that long express Ethernet link would have a strict PO, but it would be associated with that a connection request from another agent somewhere, not with any particular connection riding over the top of it at the time.
>>>>
>>>> THis is probably clear as mud, (:-) but I hope this is useful.
>>>>
>>>> Jerry
>>>>
>>>>
>>>> Jeroen van der Ham wrote:
>>>>>
>>>>> On 20/01/2010 20:24, Jerry Sobieski wrote:
>>>>>
>>>>>> - 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
>>>>>>
>>>>> Do you propose to make this implicit or explicit? That is, is there a
>>>>> "loose hop" object/marker in the STP?
>>>>>
>>>>> I would think that some kind of marker is required in order to make this
>>>>> work, and clear to the other parties that part of the STP is hidden.
>>>>>
>>>>> The loose hop object could also be used to specify whether the "loose"
>>>>> resources have been provisioned, or not, and to specify other kinds of
>>>>> information about the possible path there.
>>>>>
>>>>> Jeroen.
>>>>> _______________________________________________
>>>>> 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
>>>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100127/0d62d5a1/attachment-0001.html
More information about the nsi-wg
mailing list