Subject: Library Slides for tomorrow

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Nov 2005 16:48:00 -0500

Attached are the powerpoint slides I will be talking to tomorrow.
Yours,
Joel

---

From: "Guo, xiaoyi" <[email-masked]>
Date: Tue, 8 Nov 2005 08:38:27 +0800

All,

and my draft link :

draft-guo-forces-routing 

background reading:

ForCES Intra-NE Topology Discovery 

cheers,

Xiaoyi

---

From: "Guo, xiaoyi" <[email-masked]>
Date: Tue, 8 Nov 2005 09:22:54 +0800

All

sorry for give wrong link , i will send it again

> draft-guo-forces-routing   http://www.ietf.org/internet-drafts/draft-guo-forces-routing-01.txt
> 
> background reading:
> 
> ForCES Intra-NE Topology Discovery http://www.ietf.org/internet-drafts/draft-ietf-forces-discovery-01.txt
> 
> cheers,
> 
> Xiaoyi
>

cheers,

Xiaoyi

---

From: Alistair Munro <[email-masked]>
Date: Tue, 8 Nov 2005 07:23:53 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Nov 2005 11:51:53 -0500

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