[Nsi-wg] Path Object information/function

Tue Jan 26 12:16:38 CST 2010

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

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

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

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.

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.

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

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.  

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. 

>
> 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 ?...
> -- 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 <mailto:nsi-wg at ogf.org>
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>   
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto: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/20100126/fce38b1b/attachment.html 