Subject: Re: [issue32] Packet Redirect

From: Weiming Wang <[email-masked]>
Date: Wed, 6 Jul 2005 22:44:47 +0800

Joel,

I tend to agree with your idea below except the index.  Could you give more details on its necessity? Thanks.
As a result, the agreeable format to me seems like:

Redirect TLV, whith contains
    LFB class ID
    LFB instance ID
    operation TLV (REPORT), which contains Path-Data
    Packet TLV

We further define that that Path-Data should supply enough information for the followed packet. At least it should include information about the port number the redirect packet is input(sink LFB) or is output (source LFB), and the redirect packet type. How this is defined is left to model where redirect LFBs and the attributes are defined.

We need to solve this a little sooner.

thoughts? 

Thanks,
Weiming

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
Subject: Redirect Message

> Based on discussion, and based on my earlier message that specific protocol 
> messages may have different top level TLVs, here is a description of the 
> contents of a redirect message.
> 
> A redirect message will contain a redirect TLV.
> A redirect TLV consists of three fixed fields, and meta-data TLV, and the 
> packet.
> The fixed fields are
> o the LFB Class ID of the redirect source or redirect sink LFB on the FE 
> associated with this packet
> o the LFB Instance ID of the redirect source or redirect sink LFB on the FE 
> associated with this packet
> o an index within that LFB to identify configured properties of the packet.
> 
> The meta-data TLV contains dynamic information needed by the FE or CE to 
> process the packet.  This will need to be spelled out in more detail.  It 
> may need to use path encoding.
> 
> Following this will be the packet.
> 
> Yours,
> Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Jul 2005 16:09:57 -0400

After some discussion, the operational data may be simpler than I had been 
thinking.
We can simply attach (in some reasonable TLV format) all the meta-data.
So packets from the CE come with meta-data, and the CE gets all the 
meta-data from the FE associated with a packet.
That ensures that all the necessary information is available, without 
making the redirect LFBs complex.

Yours,
Joel

At 10:44 AM 7/6/2005, Weiming Wang wrote:
>We further define that that Path-Data should supply enough information for 
>the followed packet. At least it should include information about the port 
>number the redirect packet is input(sink LFB) or is output (source LFB), 
>and the redirect packet type. How this is defined is left to model where 
>redirect LFBs and the attributes are defined.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Jul 2005 22:38:27 -0400

There is a whole section on meta-data in the model document.
I would expect most meta-data fields to be 32 bits.
The CE can choose to use a meta-data classifier and multiple meta-data 
fields in order to steer the packet to the right LFB.  And the CE will know 
what meta-data field the LFB will use for selecting among its ports.

This relates to a larger question for the list...
We NEED an LFB library.
Please!
To do this, we need folks to actually write definitions of LFBs.
(I think we have an editor who is likely to be willing to pull things 
together.  At least I hope so.)
There are a lot of LFBs that need writing.
If this WG doesn't start producing them, it won't happen.

To get back to your question Weiming, given a set of LFB definitions and 
the meta-data they use, I can better specify what the CE will send / 
receive.  But in  an abstract sense, since it will be information flowing 
between the redirect LFB and the eventual interface LFB, the way the model 
prescribes to carry that information is as meta-data.  This is the same 
meta-data that will need, for example, to come out of longest-prefix-match 
and next-hop resolution LFBs.  After all, they need to be able to direct 
packets to be shipped out specific interfaces, with specific headers, etc.

Yours,
Joel

At 10:27 PM 7/6/2005, Wang,Weiming wrote:
>A very simple question then, how many bits we then can assign to the 
>meta-data like the port number ?
>
>thanks,
>weiming
>
>
>To: "Weiming Wang" <[email-masked]>; <[email-masked]>
>Sent: Thursday, July 07, 2005 4:09 AM
>Subject: Re: [issue32] Packet Redirect
>
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 6 Jul 2005 23:07:13 -0400

> what meta-data field the LFB will use for selecting among its ports.

  Sounds good to me.

> If this WG doesn't start producing them, it won't happen.

  This WG isn't alone in that respect.

  Alan DeKok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 6 Jul 2005 23:35:38 -0400

> If this WG doesn't start producing them, it won't happen.

I was going to ask for a slot to present a couple of the LFBs (Port and
IPv4) that Steve B. and I were supposed to be working on. I figured this
is the only way to get people to pay attention.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Jul 2005 10:02:48 -0400

This looks good to me.
My only quibble (minor difference) is with the description that the 
identifier portion of the meta-data ILV is assigned by the model.  We have 
not worked this out, but I think that the identifiers are probably going to 
end up assigned by the CE.
(The implication of this is that if one CE takes over for another, it may 
have to do some analysis to get the meanings for the meta-data 
identifiers.  But it should be simple to find the LFBs where the meta-data 
is created, and determine what ID is configured to be used for it.  And 
this needs to be described somewhere in either the model or the protocol 
document.  I think it will go in the meta-data portion of the model draft.)

Yours,
Joel

At 09:25 AM 7/15/2005, Wang,Weiming wrote:
>Hi all,
>
>I tried to compose a text for the update of the redirect message part in 
>the attachment, based on our current discussions . Pls send coments on.
>
>Thanks,
>Weiming
>
>To: <[email-masked]>
>Sent: Thursday, July 07, 2005 10:38 AM
> > > > >We further define that that Path-Data should supply enough 
> information
> > > for
> > > > > > o the LFB Instance ID of the redirect source or redirect sink 
> LFB on
> > > > > the FE
> > > > > > o an index within that LFB to identify configured properties of 
> the
> > > packet.
> > > > > >