[Nsi-wg] Path Object information/function

Mon Jan 25 13:59:22 CST 2010

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.

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.

3) For some requests the NRM may not want to be advertised/ known by all other NRMs.  Is that possible?

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.

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.

-- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100125/7163f075/attachment.html 