Subject: FW: LFB topology reconfguration

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 5 Nov 2003 18:53:46 -0800

Oops ... forgot to cc to the list. Too late into the night :-)

>  -----Original Message-----
> From:         Yang, Lily L  
> Sent: Wednesday, November 05, 2003 6:42 PM
> To:   'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M. Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim'
> Subject:      LFB topology reconfguration
> 
> Some clarifications:
> 1) LFB topology (the "graph") reprensents state, not capability.
> 2) There are different ways to represent topology capability. One way is to list all the possible graphs and name them up front. Then to reconfigure the LFB topology is to switch between the different graphs. Another way is to describe the linkage constraint (like LFB A can only be followed by LFB B and C but not D).  We can argue which is more flexible, efficient etc later. 
> 
> But I still have some questions of my own. 
> 1) How feasible & frequent it really is for an FE to change from service A to B at runtime? I heard a few people said "yes, we do that today". I would really like to hear a few concrete examples and understand what is involved at the FE and CE to accomplish that. I don't consider recompiling codes as dynamic run time configuration.  
> The reason that I am asking this is that I don't want to end up designing some feature that is cool but nobody can really uses in  the products.
> 
> 2) Is providing ability to switch between graphs flexible enough for topology reconfiguration? I realize it is limited. But is it good enough?
> 
> 3) Do we really want the ultimate flexibility to rearrange LFB by adding (instantiating) new LFB instances, deleting LFB instances, or re-connecting two LFBs (by deleting and then adding connections)?
> Again, we can do this in ForCES, but only if people really see the need/benefit of it.
> 
> 4) I imagine before you change service on FE from A to B, you probably have to stop sending packets to this FE all together if you don't want to have unpredictable behavior or loss of traffic temporarily. So it is almost equivalent to take down an FE and plug in a new one later, isn't it? 
> 
> 5) For those of you who are invovled in NPF -- Is NPF supporting dynamic LFB topology? We want to align ForCES and NPF to the same direction.
> 
> Lily

---

From: Alex Audu <[email-masked]>
Date: Thu, 6 Nov 2003 17:14:34 -0600

Hi Lily,

Not only service change from A to B, but also, service level maintenance within
some constraints falls within bounds in my view. For example, one may want
to maintain a certain level of QoS which may require some sort of feedback
process to dynamically bring in more resources (LFBs) to make up for increased
demands, or loss of resources in some other NE.  This sort of change may need
to take place much more often than the once-in-a-while service change.

Regards,
Alex.

---

From: Weiming Wang <[email-masked]>
Date: Fri, 7 Nov 2003 09:53:28 +0800

Hi Lily,

I aslo would like to argue that even micro-change  in a same servie may result in
LFB and its connections change. Alex takes the QoS levels, I just want to take a RSVP connection
setup as a consideration. When we deploy resources for a new RSVP connection, can we really do it only 
just by changing some LFB attributes?  I think current all-in-one routers actually have already made such
resources dynamic deployments, which, when reflects into ForCES architeture, are LFB changes. Actually I 
think such changes are not as awful to do as we might think,  especially when the resources are already 
managed by a center network processors. 

Regards,

Weiming