[Nsi-wg] Fwd: Thoughts on a basic topology model for NSI

[John MacAuley]

Thank you Jerry, it does clear it up.  Also, I did not think you 
dismissive at all.  I posed an extremely weak argument based on a desire 
to save myself work, and being new to the group, wanted to see the 
dynamics in action :-)

On 10-02-10 12:35 AM, Jerry Sobieski wrote:
> Hah! :-)  Along with swiss cheese problem, you also end up with idle 
> reverse bandwidth provisioned but sitting unused and blocking other 
> circuits...but the user is paying for it so hey whats not to like? :-)
>
> I didn't mean to sound too strident in refuting the bidirectional 
> circuit practice John.  I know it has been a common and standard 
> practice in nearly every network for many years.   Sorry if it seemed 
> a bit dismissive.   We don't want to preclude a symetric bidirectional 
> circuit, just make sure that we aren't forced into them as the 
> standard service instance.   For the upcoming document we decided that 
> we'd accept unidirectional connections as the basic "coin of the relm" 
> and address more sophisticated groupings, routing, and provisioning 
> issues in the next version.   We do indeed want to explore the issues 
> of diverse routing, SRLGs, Point-to-mulitPoint and MP to MP path 
> computing, decomposition, and manipulation - but we just didn't have 
> time to address those issues by OGF.
>
> Actually, this group is *not* supposed to be dealing with topology 
> exchange or even provisioning...those are process we recognize and 
> consider, but NSI doesn't make a specification regarding them.   NSI 
> only deals with the RA-PA relationship - i.e. the semantic 
> functionality necessary to establish trust and field service 
> requests.   We have decided that one service that NSI will need to 
> include is the Connection Service, and this was important enough that 
> we felt it necessary to define the functional semantics for that NSI 
> service as well.  So we are developing the functional semantics 
> necessary provide such a service in a fashion that lends itself to 
> both WS and lowlevel protocol implementations.
>
> Hope this helps
> Jerry
>
> John MacAuley wrote:
>> Oh Jerry I see you are a progressive thinker.  I assume my arguement 
>> of "bidirectional symmetric bandwidth is the way God intended" will 
>> not work with you then?  I can't argue with your points.  VCAT was 
>> designed to help carriers with the swiss cheesing problem, as well as 
>> permit growth of existing connections, but I get a warm sense of 
>> comfort when an equivalent number of timeslots are provisioned on 
>> each of the transmit/receive pairs at layer 1.
>>
>> So just for my clarification - this working group is only dealing 
>> with the protocols used to exchange topology and signal the reservation?
>>
>> John.
>>
>> On 10-02-09 3:47 PM, Jerry Sobieski wrote:
>>> Comments in line:
>>>
>>> John MacAuley wrote:
>>>>
>>>> 1. Aggregation and summarization.
>>>> 2. Routing in both space and time.
>>>> 3. Unidirectional versus bidirectional.
>>>>
>>>> 1. Aggregation and summarization.
>>>> There are a few advantages to abstracting a domain into a single 
>>>> virtual node beyond the first point made with respect to security.  
>>>> First of all, it simplifies the inter-domain topology picture since 
>>>> only edge links (UNI and E-NNI ports) are advertised external to 
>>>> the domain.  It also permits internal routing decisions to be made 
>>>> exclusively by the NRM for that domain, without having to expose 
>>>> complex routing policies externally for PCE to utilize. 
>>> For future reference, summarization does not always mean complete 
>>> summarization.  I.e. a network could advertise an abstract  topology 
>>> that is just simpified - not just a single node, or even just edge 
>>> nodes....  An "abstracted" topology need only provide valid topology 
>>> information - not necessarilly congruent or even summarized 
>>> topology.  For instance, a network could advertise a much more 
>>> complex internal topology than it actually has...how would a neigbor 
>>> know that its BS? :-)  This is an issue for the DToX group...
>>>
>>> There are a number of advantages to summarization - the most notable 
>>> is the potential reduction in topology that gets distributed, but 
>>> there is also a cost: reducing topology information makes it more 
>>> difficult to find optimal paths (or even just a "better" set of 
>>> paths).  So I don't think NSI should make recommendation on topology 
>>> summarization - but hopefully our minimal topology model will allow 
>>> it.    As Jeroen alludes - hiding topology can be costly.  (But so 
>>> can exposing it:-)  I suggest our topo model should be able to 
>>> support whatever topology a domain /chooses/ to expose - and leave 
>>> for another day/another working group the consideration of what 
>>> topology should best be distributed and how.
>>>>
>>>> .    Adaptation decision -- at what point in the network should a 
>>>> higher layer payload (Ethernet) be wrapped into a lower layer 
>>>> service (STS) for transport across the network?
>>>>
>>>> .    Inter-layer routing decisions -- When should a new lower layer 
>>>> service be created to meet the additional demand of the higher 
>>>> layer services requested?
>>> Again, while there is some good discussion that could be had on this 
>>> topic, this is really a topology distribution conversation.  
>>> Different domains will use different heuristics to make that 
>>> decision.  What we need to do is to make sure that once the decision 
>>> is made, that the NSI will be able to implement it and inter-operate 
>>> with it.   I.e. how a network decides when its necessary to build an 
>>> express link is not our decision, but when they do, we should be 
>>> able to construct that connection with NSI, and have a model that 
>>> allows that connection to then become part of the topology db and 
>>> thereby utilized for future path finding.  I think we are good on 
>>> this point.
>>>
>>> The one thing NSI should (IMO) stipulate is that the ingres and 
>>> egress framing will be as requested by the Connection Request.  I.e. 
>>> if the ingress STP is an ethernet access framing, and the output STP 
>>> is say SDH framing (a trib), then adaptation is necessary -its not a 
>>> tunnel.   However, if the request specified ethernet STPs on both 
>>> ingress and egress, then the pathfinder could a) provision a flat 
>>> ethernet connection, b) adapt the payload to sonet framing and then 
>>> adapt it back to ethernet before reaching the egress, or c) build a 
>>> sonet tunnel that encapsulates the ethernet framing and that pops 
>>> out before reaching the egress STP.   These are sublty different 
>>> approaches.   The real question is how complex does the topology 
>>> need to be? and what does this do to the computational complexity of 
>>> the pathfinder algorithm?   I think the only thing we need from this 
>>> issue is to make sure the minimal topological model can represent 
>>> functional nodes like "adaption"...which it can (IMO).
>>>
>>>> .    Policy based routing -- although adaptation and inter-layer 
>>>> routing could be considered policy based decisions, with this point 
>>>> I am referring to policies applied to path computation that could 
>>>> guide a route through the network.  These attributes should be 
>>>> considered different than the standard constraint based routing 
>>>> attributes of link cost and shared risk link group values.  For 
>>>> example, certain internal routes may be exclusively reserved for a 
>>>> particular class of service or class of user.  My example here was 
>>>> always routing Inder's requests over the longest route and dirtiest 
>>>> fiber you could find.
>>> I suggest that these are *all* constraints that can be considered 
>>> generally rather than making special cases for inter-layer 
>>> adaptation, special scheduling corner cases, special authorization 
>>> requirements, on an on...    If pathfinding has to consider special 
>>> conditions for any link, then it needs to do so for every link... it 
>>> doesn't buy you anything to make some links subject to special 
>>> processing - you then have to check every link to see if special 
>>> processing condition applies.     It is my assertion that the 
>>> measure and value of our minimal topology model will be the ability 
>>> for it to support these issues *without* specialized handling.  If 
>>> we choose to optimize some aspect later, thats ok as long as the 
>>> model itself is not broken by doing so.  One optimization that 
>>> doesn't break the model is the constraint prioritization: one 
>>> constraint may prune the search space faster than another.  This is 
>>> something that is general, and can be applied to any/all constraints 
>>> without breaking the generality of a constraint based search for 
>>> pathfinding.
>>>
>>> One thing we decided we needed to consider was how we implement a 
>>> "modify" semantic for connections.
>>>
>>> Just to digress a bit into the topology discussion, distributing all 
>>> topology to all networks is probably going to be a scaling issue in 
>>> both complexity and security, and even our R&E networks are big 
>>> enough to pose that scaling issue.  So a local PathFinder is not 
>>> going to make a very good decision about some far away network link 
>>> allocation.  So, IMO, we need to view topology distribution and 
>>> pathfinding in a more localized manner.   Possibly using a mix of 
>>> local link state to make local path decisions but based upon 
>>> reachability presented though something akin to an AS path vector 
>>> for choosing exit points to next hop domains.    And let downstream 
>>> pathfinders perform downstream Pathfinding/allocation.   This 
>>> doesn't prevent or preclude domains from dumping all their topo 
>>> infromation to their neighbors, but having a model that allows both 
>>> methods would probably be a best fit - and small communities like 
>>> R&E might share more complete topo info, while larger  networks 
>>> might keep more details localized and just advertise reachability to 
>>> neighbors...
>>>>
>>>>
>>>> 3. Unidirectional versus Bidirectional.
>>>> Although I totally understand that a unidirectional service is a 
>>>> basic building block, there are a number of problems going with 
>>>> this model in a layer 1 network.  Over time is can result in the 
>>>> undesirable side effect of Swiss cheesing timeslots on layer 1 
>>>> links.  If this is truly to be considered a functional solution in 
>>>> a highly dynamic network we need to make sure this does not become 
>>>> an issue.  Secondly, in a layer 1 network bidirectional 
>>>> provisioning is an atomic operation reserving equivalent timeslots 
>>>> on transmit/receive pairs.  This can cut the time of provisioning 
>>>> two equivalent unidirectional circuits in half.  Lastly, it makes 
>>>> my life a lot easier :-)
>>> I assert that not "swiss cheesing" a Sonet/sdh layer is not a 
>>> compelling argument for an architectural decision today (:-)   
>>> First, I think with VCAT and LCAS this issue is not so big a 
>>> resource problem anymore.  Second, old symetric models for sonet/sdh 
>>> circuits supporting voice services are not typical of present day 
>>> connection requirements for data circuits.  Data circuits in general 
>>> exhibit asymetric loading, and TCP flows tend strongly toward 
>>> asymetric loads.   Third, there is no apriori requirement that a 
>>> connection be symetric pathwise or capacitywise.  There may be some 
>>> assumptions by TCP that RTT is symetric, but that hasn't been a 
>>> reliable assumption for years.   And there is a truck load of flow 
>>> control algorithms in the literature that could and have been 
>>> adapted for IP traffic over big fat [possibly asymetric] pipes.  And 
>>> fourth, if we expect to support multipoint services in future 
>>> versions, the notion of unidirection path objects and connections 
>>> provides a much better basis for assembling components of a 
>>> multipoint connnection where bidirectionality means something 
>>> significantly different.
>>>
>>> So while I believe you that real networks may have been historically 
>>> concerned about the sonet groomng/garbage collection, I don't 
>>> believe this is a significant concern in present/emerging networks.
>>>
>>> Thanks for the comments John.  Interesting thoughts.
>>> Jerry
>>>> John.
>>>>
>>>>> *From: *Jerry Sobieski <jerry at nordu.net <mailto:jerry at nordu.net>>
>>>>> *Date: *February 2, 2010 2:24:10 PM EST
>>>>> *To: *"nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>" <nsi-wg at ogf.org 
>>>>> <mailto:nsi-wg at ogf.org>>
>>>>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
>>>>>
>>>>> Hi all-
>>>>>
>>>>> Relative to our brief discussion last week about topology and the 
>>>>> NSI...
>>>>>
>>>>> We want the NSI to offer more power and options to the "user" - to 
>>>>> break out of the traditional carrier models for interacting with 
>>>>> the user.   And I think our notions of Requesting aAgents and 
>>>>> Providing Agents does that nicely and in a very elegant and 
>>>>> scalable fashion.
>>>>>
>>>>> However, we still have a lot of discussion about pathfinding - 
>>>>> about how the agents will go about decomposing a path request into 
>>>>> sub-paths for tree or chain model processing, or how we decide 
>>>>> which NRMs are responsible for a particular end point, etc.  These 
>>>>> all deal with *topology*.   There are quite a few notions we take 
>>>>> for granted that require some sort of topology model.  For 
>>>>> instance:  a Service Termination Point.  Whatever we end up caling 
>>>>> it, the semantics of an STP is that it represents a point in the 
>>>>> topology where a service connection can terminate.  We talk about 
>>>>> capturing path information for monitoring...that requires a notion 
>>>>> of how the topology is defined.   There are lots of topologically 
>>>>> based assumptions we need to be more explicit about.
>>>>>
>>>>> So this set of slides tries to capture some thoughts of mine on 
>>>>> how we can pose a simple minimalist topological model sufficient 
>>>>> for our NSI purposes.   I think it is consistent wth our thoughts 
>>>>> and discussions.  And while it may bump into things that the NML 
>>>>> WG is considering, I doubt a) we have come up with anything 
>>>>> conflicting, and b) we certanly have not gone to the details of 
>>>>> how to describe or distribute a topology database - we just assume 
>>>>> we have a TopoDB and that is contains these basic constructs.
>>>>>
>>>>> Comments are welcome...Its only a draft for consideration...
>>>>> Jerry
>>>>>
>>>>> While the NSI protocol itself does not impose a particular 
>>>>> topology on the transport plane or the agents that manage it, we 
>>>>> do impose some notions on the Connections we construct - e.g. that 
>>>>> the NSAs will, as a group, be able to construct and reserve a 
>>>>> suitable path for the request.
>>>>
>>>>
>>>>> _______________________________________________
>>>>> 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/20100210/a8c13e49/attachment-0001.html