Subject: 答复: [issue32] Packet Redirect

From: 贾凤根 <[email-masked]>
Date: Fri, 15 Jul 2005 22:19:51 +0800

I'm totally agree with Joel, in fact we are actually implementing this and it works well. I think the control plane portion of forces should assigned the port number according to the FE association sequence, and the other meta data are determined by the model group.And I think the force protocol should define how the LFB ID is defined by the arriving of the association message.
Fenggen Jia
 -----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2005年7月15日 22:03
收件人: [email-masked]
主题: Re: [issue32] Packet Redirect

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
>
>----- Original Message -----
>From: "Joel M. Halpern" <[email-masked]>
>To: <[email-masked]>
>Sent: Thursday, July 07, 2005 10:38 AM
>Subject: Re: [issue32] Packet Redirect
>
>
> > 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
> > >
> > >
> > >----- Original Message -----
> > >From: "Joel M. Halpern" <[email-masked]>
> > >To: "Weiming Wang" <[email-masked]>; 
> <[email-masked]>
> > >Sent: Thursday, July 07, 2005 4:09 AM
> > >Subject: Re: [issue32] Packet Redirect
> > >
> > >
> > > > 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:
> > > > >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: "Wang,Weiming" <[email-masked]>
Date: Sun, 17 Jul 2005 17:32:02 +0800

Hi Joel, and Fenggen, 

I also have the same concern as Hormuzd that why meta-data ID should be assigned by CE? If the ID is assigned by CE, it actually implies the ID is dynamic, rather than static. I suppose the ID is static, i.e., LFB definitions statically assign it. Obviously, meta-data received by a redirect sink LFB will have meta-data definition of the LFB the redirect packet is from, while meta-data sent from CE to a redirect source LFB will be treated as a meta-data of the redirect souce LFB's meta-data, which is defined by the LFB.

Anyway, I suppose we may close the #32 issue on the whole, only leaving above question for some more discussion.

Thanks,
Weiming

----- Original Message ----- 
<[email-masked]>:

Joel M. Halpern [mailto:[email-masked]]:

This looks good to me.

Yours,
Joel