Subject: Re: FW: LFB topology reconfguration

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 7 Nov 2003 10:05:52 -0800

Alex --
I am a bit confused when you said "bring in more resources (LFBs)" -- Do you mean more instances of the same LFB, or more resources for existing LFBs? What do you mean by resources here? Like memory, processing, bandwidth on FE? 
Can I ask you a favor here? Can you draw the example you have in mind for me :-) ?

I would really like to collect some examples that people have in mind and examine them to understand what are required here for FE model to support these examples. As I said (in my response to Weiming), how we model LFB (granularity), how we model the datapath, all affect how dymanic the topology will become. Comparing to six month ago, I think we have better ideas on these issues but by no means firm and complete. So I would like to use some examples as a way to sanity-check our thinking here. That is why I am pushing for some examples with certain level of details. I believe these examples can help deepen our discussion on the subject.

Thank you!
Lily

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Alex Audu
> Sent: Thursday, November 06, 2003 3:15 PM
> To: [email-masked]
> Subject: Re: FW: LFB topology reconfguration
> 
> 
> 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.
> 
> "Yang, Lily L" wrote:
> 
> > 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: Fri, 7 Nov 2003 17:10:47 -0600

Exactly. This assumes that all your resources for processing traffic can be
mapped somewhat to some LFBs (either in whole or in part).  If a configured
channel is getting overwhelmed due to excessive traffic, you can react to this
scenario in one of two ways : drop packets or accommodate the traffic by
springing in more channels to cope with increased demand. It is not unlike
bringing a new link on-line on a macro scale. But definitely, you can imagine all
the ramifications of this action on the microscopic LFB scale.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Fri, 7 Nov 2003 17:15:12 -0600

To add to my previous e-mail, one can also imagine logic devices that
react to security violation detection by causing changes in some LFBs.

Regards,
Alex.