Subject: Re: Library Slides for tomorrow

From: "Stephen Nadas (NC/TNT)" <[email-masked]>
Date: Tue, 8 Nov 2005 11:22:54 -0600

Hi Joel, 

I read this as well.  I am also generally ok, some comments, 
If you want, we can discuss - I am at ietf also. 

- Structure: I have grouped the Classes into sections
  Groupings are fairly arbitrary 

  SJN - ok

- Connectivity LFBs: This includes provision for stacking 
  connectivity (PPP stacked on Serial Line, Frame Relay, 
  or Ethernet) 
  
  SJN - something to think about: in our impl, this cfg info 
  would also be saved an OAM (sub-)interfaces component - 
  I wonder if IM considerations shld be mentioned or referenced 
  here?  Importance level of this seems to be related to whether 
  vif notion outcome is to be described.    

- Classifier LFBs: Separate LPM classifier 
  
  SJN - important that it is possible to model/implement this 
  aspect in flexible ways  

- Classifier LFBs: Trying to fold LPM into the general classifer 
  structure hurt my head  Should we have different classifiers? 

  SJN-yes, though in some cases it maybe that some information 
  or some structure is shared between them - from control plane 
  point of view, the metadata can pgrm   the precise dataplane 
  details.  

- Queue & Scheduler LFBs: Separating queue and scheduler has 
  been found useful in other models 

  SJN-yes; at least available as option 

Cheers,
Steve 

Stephen Nadas                           Ericsson IPI       
[email-masked]              920 Main Campus Dr.
Voice:  +1-919-472-9935 Fax: x/9999     Suite 500
Mobile: +1-919-522-0991 ECN: 802 29935  Raleigh, NC 27606 

-----Original Message-----
From: Forwarding and Control Element Separation [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, November 08, 2005 11:52
To: [email-masked]
Subject: Re: Library Slides for tomorrow

These comments are quite accurate.  Thanks for taking a look.

The Next Hop LFB is separate in the document from the classifier, although it is in the same section.  I left it out of the slide by accident.  Sorry.

We definitely need a meter LFB.

I'll let some other folks tell me what the LFBs for IPSec should be.  I don't know if that is one LFB, or more than one.
I will be happy to include it in the document if it shows up.

I am not sure that the "virtual interface" needs to exist in terms of LFBs.  When I was writing the connectivity LFB, I tried to separate out some of the logic, and it seemed to me it was too entangled.  But if there is a reasonable decomposition I would be happy to include it.
This is a good point to mention one thing.  The LFB decomposition and properties need to reflect the packet processing.  They do not need to reflect the structure that the CE may want to present to the configuring user.  The CE may choose to present various combinations of information from several LFBs as if they were one (for example an IP interface with all its properties is probably a CE construct.)

The ICMP and ARP functions clearly can be done in the CE.  We may well want to simply say that they should be.
Equally, to generate ICMP messages of various sorts requires detection by the various other data handling LFBs.  The idea is that they would direct the packet, with suitable meta-data to the ICMP LFB who would be able to actually build ICMP packets.  I would not expect the different processing LFBs to know how to generate those packets.

Thanks,
Joel

At 02:23 AM 11/8/2005, Alistair Munro wrote:
>Hi Joel,
>
>>Attached are the powerpoint slides I will be talking to tomorrow.
>
>Looks good. Couple of remarks:
>
>1. Classifiers seem to crop up all over the place in practice - IPSec, 
>QoS traffic type, etc., so a generic function that can be given rules 
>for metadata as well as packet fields useful.
>2. LPM can usefully be split into 2 sub-functions: prefix table and 
>next-hop. Agree it should be done separately.
>3. Probably need IPSec LFBs - encap/decap, verification (plus 
>classifier),
>+ ...
>4. Need a metering LFB - not sure if this is a classifier or something else.
>5. Some kind of abstraction of ingress and egress "virtual" interface 
>LFBs would be useful to separate the termination of packet processing 
>from the details of the physical interfaces.
>6. Some ICMP packets will be generated in the fast-path but the 
>functionality need not be in a specific ICMP LFB.
>7. I think ARP is better put in the CE - it just seems a better place 
>for admission control and validation.
>
>Regards,
>
>Alistair
>
>--
>Alistair Munro,
>Principal Engineer, U4EA Technologies Ltd.
>City Point, Temple Gate, Bristol, BS1 6PL, U.K.
>E-mail: [email-masked]
>Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
>+44-7974-922-442;
>Fax: +44-117-373-6751
>Web: http://www.u4eatech.com