From hadi@mojatatu.com Thu Feb 2 06:01:52 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAC321F8693 for ; Thu, 2 Feb 2012 06:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.805 X-Spam-Level: X-Spam-Status: No, score=-100.805 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZjehhK57Vlz for ; Thu, 2 Feb 2012 06:01:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B245A21F8681 for ; Thu, 2 Feb 2012 06:01:51 -0800 (PST) Received: by iagf6 with SMTP id f6so3896593iag.31 for ; Thu, 02 Feb 2012 06:01:51 -0800 (PST) Received: by 10.50.160.194 with SMTP id xm2mr3445411igb.18.1328191311256; Thu, 02 Feb 2012 06:01:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.68.142 with HTTP; Thu, 2 Feb 2012 06:01:31 -0800 (PST) In-Reply-To: References: <201201151437339009129@mail.zjgsu.edu.cn> <201201161010116180192@mail.zjgsu.edu.cn> <4F13A88B.20803@joelhalpern.com> From: Jamal Hadi Salim Date: Thu, 2 Feb 2012 09:01:31 -0500 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , Chuanhuang Li , forces Subject: Re: [forces] IPv4prefix packing X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:01:52 -0000 Hi Weiming, There are some implementation ties to what i described - but having fields = being alignment accessible when it doesnt cost you anything is pragmatic. Reserve= d fields are a common occurrence in protocol and data definitions (we have on= e in the forces header for example for this very same reason). Sometimes it is hard to achieve that goal. For example when you have MAC addresses that straddle across 32 bit fields. In the Linux kernel, some equipment ends up adding 2B padding after the ethernet header after receiving the pac= ket to align the IPv4/6 header so that when it is accessed, there are no alignm= ent penalties. So _how you send things on the wire_ makes a difference. In the same spirit of thought, but this one is not as a big deal, for EncapTableEntry, aligning on 32 bits: DstMac(32 bits) DstMac(16 bits): SrcMac (16 bits) SrcMac(32 bits) VlanID (16 bits): L2PortID(16 bits) L2PortID(16 bits) It would be nice maybe to have it as: DstMac(32 bits) DstMac(16 bits): SrcMac (16 bits) SrcMac(32 bits) VlanID (16 bits): Reserved (16bits) L2PortID(32 bits) Actually VlanID is 12 bits so the reserved could be reserved1(4 bits) and reserved2 (16bits) cheers, jamal On Tue, Jan 31, 2012 at 10:45 PM, Wang,Weiming wro= te: > Hi Jamal and Chuanhuang, > > I agree it seems like an implementation issue, whereas it also seems a go= od way of optimization to the lib xml file, i.e., users may be rewarded =A0= by the change at no extra cost. > > As a result, I suggest to make the component ID order as much as possible= to consider the alignment for all LFBs. > > On the reserved field, I'm not sure if we now need this, or if we do so f= or all LFBs, the xml may look a little usual, with too many reserved fields= ? > > thanks, > Weiming > > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > Aside from the packing issue, lets say your implementation was how i desc= ribed > the most optimal layout out to be and you merely translated on where > to put things > as they come in from the wire with this format; on a lot of hardware, > the processing is going to consume =A0more cycles. For example, two fetch= es > will be required to retrieve HopSelector from the wire format. > So it is pragmatic to make this change. > > cheers, > jamal > > On Sun, Jan 15, 2012 at 11:33 PM, Joel M. Halpern w= rote: >> I started out thinking exactly the way you describe Chuanhuang. >> Then Jamal pointed out to me that when one uses the full-data TLV we pac= k >> all of the data together. In order as defined by the LFB. At which point >> the alignment comes into play. >> >> Yours, >> Joel >> >> >> On 1/15/2012 9:10 PM, Chuanhuang Li wrote: >>> >>> Hi,Jamal >>> I have some different opinions. >>> I think the LFB definition is not a specific implementation. It just a >>> logical and >>> abstract definition. User can implement the LFB in different ways. But = the >>> important >>> is that CE could use ForCES protocol to control these LFBs implemented = by >>> different users. >>> Byte alignment is an implementation problem. If the reason for adding t= he >>> definition field is >>> just this one, from my point, i think we needn't change. >>> >>> Exactly, there may be other byte alignment cases, not just this one. Fo= r >>> example, if a "string" type >>> component is a member of "struct" type, such as the definition of >>> "LFBLinkType" in FEObject LFB. >>> >>> Yours, >>> Chuanhuang >>> =3D=3D=3D=3D=3D=3D=3D 2012-01-15 20:51:42 Jamal Hadi Salim, wrote: =3D= =3D=3D=3D=3D=3D=3D >>> >>>> Sorry, I didnt answer the core part of your question: >>>> We dont need this reserved field, but we want to annotate it >>>> so nobody tries to add a new field in the future; it is also >>>> common practise (look at evolution of many headers at IETF, >>>> IPv4, TCP etc). >>>> >>>> BTW: In the xml i sent you, I made a mistake in the IDs; i think ID=3D= 3 >>>> is repeated twice. >>>> >>>> cheers, >>>> jamal >>>> >>>> On Sun, Jan 15, 2012 at 7:44 AM, Jamal Hadi Salim >>>> wrote: >>>>> >>>>> Hi Chuanhuang, >>>>> >>>>> There are several reasons. One is: RAM is abused a lot more. >>>>> Ive attached a small C program with four possible layouts of the fiel= ds. >>>>> In the suggested case we save 3Bytes compared to current definition. >>>>> Try running it to see what I mean. Then try to imagine you have 500K >>>>> such >>>>> fields and how much RAM you can save. >>>>> Not only for RAM, but if you were to send this structure on the wire = - >>>>> the most efficient >>>>> way to do it is as i described. There is network equipment which will >>>>> do more than one >>>>> fetch to retrieve a field that goes across 32bit or 64bit alignment >>>>> boundaries; these >>>>> compute cycles could also be saved if you laid it out this way. >>>>> Third, to interop properly you cant send that struct with plain TLVs, >>>>> you need to >>>>> use ILVs (restricting its usefulness). >>>>> >>>>> cheers, >>>>> jamal >>>>> >>>>> On Sun, Jan 15, 2012 at 1:37 AM, Chuanhuang Li >>>>> wrote: >>>>>> >>>>>> Hi,Jamal >>>>>> I think it's no problem that we add this reserved field, if it is >>>>>> needed sometime. But can you >>>>>> detailed the possible occasion to use this field? Thanks! >>>>>> >>>>>> Yours, >>>>>> Chuanhuang >>>>>> =3D=3D=3D=3D=3D=3D=3D 2012-01-14 21:59:17 Jamal Hadi Salim, wrote: = =3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>>> The current IPV4 prefix is not efficient to send on the wire. >>>>>>> Can we re-arrange and add an 8 bit reserved field to make it more >>>>>>> efficient. >>>>>>> XML suggestions attached. >>>>>>> >>>>>>> cheers, >>>>>>> jamal >>>>>>> >>>>>> >>>>>> >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From chuanhuang_li@hotmail.com Thu Feb 2 08:05:39 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9537D21F85E5 for ; Thu, 2 Feb 2012 08:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.616 X-Spam-Level: * X-Spam-Status: No, score=1.616 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzzGB-70zD5r for ; Thu, 2 Feb 2012 08:05:38 -0800 (PST) Received: from snt0-omc2-s40.snt0.hotmail.com (snt0-omc2-s40.snt0.hotmail.com [65.54.61.91]) by ietfa.amsl.com (Postfix) with ESMTP id 244D521F85DD for ; Thu, 2 Feb 2012 08:05:38 -0800 (PST) Received: from SNT134-W25 ([65.55.90.72]) by snt0-omc2-s40.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 08:05:37 -0800 Message-ID: Content-Type: multipart/mixed; boundary="_7df6f95c-7a39-4e10-aac0-b62e291e4cd0_" X-Originating-IP: [221.12.10.218] From: Chuanhuang Li To: , Date: Fri, 3 Feb 2012 00:05:37 +0800 Importance: Normal In-Reply-To: References: <201201151437339009129@mail.zjgsu.edu.cn>, , <201201161010116180192@mail.zjgsu.edu.cn>, <4F13A88B.20803@joelhalpern.com>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 16:05:37.0238 (UTC) FILETIME=[807C6F60:01CCE1C4] Cc: jmh@joelhalpern.com, chuanhuang_li@mail.zjgsu.edu.cn, forces@ietf.org Subject: Re: [forces] IPv4prefix packing X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 16:05:39 -0000 --_7df6f95c-7a39-4e10-aac0-b62e291e4cd0_ Content-Type: multipart/alternative; boundary="_47c18b6e-d5e9-477f-8c23-7e1132999220_" --_47c18b6e-d5e9-477f-8c23-7e1132999220_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi, Jamal and all If we consider the alignment issue, besides the type of IPv4Prefix, IPv6Prefix and EncapTable, VlanInputTable in EtherClassifier also need to be modified. The way to solve alignment with adding Reserved field, please see the attachment. I agree to Jamal's modification suggestion. But, i still think this is just an FE's implementation issue. The main goal of LFB definition is that CE can control and configure FEs implemented by different users, not guiding user to implement an FE. The alignment said in ForCES protocol and the aligment in FE's implementation are two different issues. If user sends ForCES message with TLV length not multiple of 32 bits, Padding is required. Whatever the LFB is defined, this requirement can be reached. But the LFB can be implemented in different ways. For example, the "SupportedLFBType" defined in FEObject LFB, SupportedLFBType table entry for supported LFB LFBName The name of a supported LFB class string LFBClassID the id of a supported LFB class uint32 ...... LFBName is string type, LFBClassID, uint32 type, respectively. User can implement this type in the following way: typedef struct SupportedLFBType{ UINT8 LFBName[FEOBJECTLFB_MAX_STRING_LENGTH]; UINT32 LFBClassID; ...... The macro "FEOBJECTLFB_MAX_STRING_LENGTH" used by LFBName can be any value that user wants to use (for alignment, Usually be multiple of 32 bits). But if user encapsulates the information into TLV, the string length is the actual length of the value. It is not multiple of 32 bits in most cases. Yours, Chuanhuang > From: hadi@mojatatu.com > Date: Thu, 2 Feb 2012 09:01:31 -0500 > To: wmwang2001@hotmail.com > CC: jmh@joelhalpern.com; chuanhuang_li@mail.zjgsu.edu.cn; forces@ietf.org > Subject: Re: [forces] IPv4prefix packing > > Hi Weiming, > > There are some implementation ties to what i described - but having fields being > alignment accessible when it doesnt cost you anything is pragmatic. Reserved > fields are a common occurrence in protocol and data definitions (we have one in > the forces header for example for this very same reason). > > Sometimes it is hard to achieve that goal. For example when you have MAC > addresses that straddle across 32 bit fields. In the Linux kernel, > some equipment > ends up adding 2B padding after the ethernet header after receiving the packet > to align the IPv4/6 header so that when it is accessed, there are no alignment > penalties. So _how you send things on the wire_ makes a difference. > > In the same spirit of thought, but this one is not as a big deal, > for EncapTableEntry, aligning on 32 bits: > > DstMac(32 bits) > DstMac(16 bits): SrcMac (16 bits) > SrcMac(32 bits) > VlanID (16 bits): L2PortID(16 bits) > L2PortID(16 bits) > > It would be nice maybe to have it as: > DstMac(32 bits) > DstMac(16 bits): SrcMac (16 bits) > SrcMac(32 bits) > VlanID (16 bits): Reserved (16bits) > L2PortID(32 bits) > > Actually VlanID is 12 bits so the reserved could be reserved1(4 bits) > and reserved2 (16bits) > > cheers, > jamal > > On Tue, Jan 31, 2012 at 10:45 PM, Wang,Weiming wrote: > > Hi Jamal and Chuanhuang, > > > > I agree it seems like an implementation issue, whereas it also seems a good way of optimization to the lib xml file, i.e., users may be rewarded by the change at no extra cost. > > > > As a result, I suggest to make the component ID order as much as possible to consider the alignment for all LFBs. > > > > On the reserved field, I'm not sure if we now need this, or if we do so for all LFBs, the xml may look a little usual, with too many reserved fields? > > > > thanks, > > Weiming > > > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > Aside from the packing issue, lets say your implementation was how i described > > the most optimal layout out to be and you merely translated on where > > to put things > > as they come in from the wire with this format; on a lot of hardware, > > the processing is going to consume more cycles. For example, two fetches > > will be required to retrieve HopSelector from the wire format. > > So it is pragmatic to make this change. > > > > cheers, > > jamal > > > > On Sun, Jan 15, 2012 at 11:33 PM, Joel M. Halpern wrote: > >> I started out thinking exactly the way you describe Chuanhuang. > >> Then Jamal pointed out to me that when one uses the full-data TLV we pack > >> all of the data together. In order as defined by the LFB. At which point > >> the alignment comes into play. > >> > >> Yours, > >> Joel > >> > >> > >> On 1/15/2012 9:10 PM, Chuanhuang Li wrote: > >>> > >>> Hi,Jamal > >>> I have some different opinions. > >>> I think the LFB definition is not a specific implementation. It just a > >>> logical and > >>> abstract definition. User can implement the LFB in different ways. But the > >>> important > >>> is that CE could use ForCES protocol to control these LFBs implemented by > >>> different users. > >>> Byte alignment is an implementation problem. If the reason for adding the > >>> definition field is > >>> just this one, from my point, i think we needn't change. > >>> > >>> Exactly, there may be other byte alignment cases, not just this one. For > >>> example, if a "string" type > >>> component is a member of "struct" type, such as the definition of > >>> "LFBLinkType" in FEObject LFB. > >>> > >>> Yours, > >>> Chuanhuang > >>> ======= 2012-01-15 20:51:42 Jamal Hadi Salim, wrote: ======= > >>> > >>>> Sorry, I didnt answer the core part of your question: > >>>> We dont need this reserved field, but we want to annotate it > >>>> so nobody tries to add a new field in the future; it is also > >>>> common practise (look at evolution of many headers at IETF, > >>>> IPv4, TCP etc). > >>>> > >>>> BTW: In the xml i sent you, I made a mistake in the IDs; i think ID=3 > >>>> is repeated twice. > >>>> > >>>> cheers, > >>>> jamal > >>>> > >>>> On Sun, Jan 15, 2012 at 7:44 AM, Jamal Hadi Salim > >>>> wrote: > >>>>> > >>>>> Hi Chuanhuang, > >>>>> > >>>>> There are several reasons. One is: RAM is abused a lot more. > >>>>> Ive attached a small C program with four possible layouts of the fields. > >>>>> In the suggested case we save 3Bytes compared to current definition. > >>>>> Try running it to see what I mean. Then try to imagine you have 500K > >>>>> such > >>>>> fields and how much RAM you can save. > >>>>> Not only for RAM, but if you were to send this structure on the wire - > >>>>> the most efficient > >>>>> way to do it is as i described. There is network equipment which will > >>>>> do more than one > >>>>> fetch to retrieve a field that goes across 32bit or 64bit alignment > >>>>> boundaries; these > >>>>> compute cycles could also be saved if you laid it out this way. > >>>>> Third, to interop properly you cant send that struct with plain TLVs, > >>>>> you need to > >>>>> use ILVs (restricting its usefulness). > >>>>> > >>>>> cheers, > >>>>> jamal > >>>>> > >>>>> On Sun, Jan 15, 2012 at 1:37 AM, Chuanhuang Li > >>>>> wrote: > >>>>>> > >>>>>> Hi,Jamal > >>>>>> I think it's no problem that we add this reserved field, if it is > >>>>>> needed sometime. But can you > >>>>>> detailed the possible occasion to use this field? Thanks! > >>>>>> > >>>>>> Yours, > >>>>>> Chuanhuang > >>>>>> ======= 2012-01-14 21:59:17 Jamal Hadi Salim, wrote: ======= > >>>>>> > >>>>>>> The current IPV4 prefix is not efficient to send on the wire. > >>>>>>> Can we re-arrange and add an 8 bit reserved field to make it more > >>>>>>> efficient. > >>>>>>> XML suggestions attached. > >>>>>>> > >>>>>>> cheers, > >>>>>>> jamal > >>>>>>> > >>>>>> > >>>>>> > >> > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces --_47c18b6e-d5e9-477f-8c23-7e1132999220_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hi, Jamal and all
     If we consider the alignment issue, besides the type of IPv4Prefix, IPv6Prefix and
EncapTable, VlanInputTable in EtherClassifier also need to be modified. The way to solve
alignment with adding Reserved field, please see the attachment.
 
I agree to Jamal's modification suggestion.  But, i still think this is just an FE's implementation issue.
The main goal of LFB definition is that CE can control and configure FEs implemented by different users, not
guiding user to implement an FE.  
The alignment said in ForCES protocol and the aligment in FE's implementation are two different issues.
If user sends ForCES message with TLV length not multiple of 32 bits, Padding is required.
Whatever the LFB is defined, this requirement can be reached. But the LFB can be implemented in different ways. 
For example, the "SupportedLFBType" defined in FEObject LFB,
                <dataTypeDef>
                <name>SupportedLFBType</name>
                <synopsis>table entry for supported LFB</synopsis>
                <struct>
                  <component componentID="1">
                    <name>LFBName</name>
                    < synopsis>
                      The name of a supported LFB class
                    </synopsis>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="2">
                    <name>LFBClassID</name>
                &n bsp;   <synopsis>the id of a supported LFB class</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  ......
LFBName is string type, LFBClassID, uint32 type, respectively.
User can implement this type in the following way:
typedef struct SupportedLFBType{
        UINT8    LFBName[FEOBJECTLFB_MAX_STRING_LENGTH];
        UINT32   LFBClassID;
        ......
The macro "FEOBJECTLFB_MAX_STRING_LENGTH" used by LFBName can be any value that user wants to use
(for alignment, Usually be multiple of 32 bits).
But if user encapsulates the information into TLV, the string length is the actual length
of the value. It is not multiple of 32 bits in most cases.
 

Yours,
Chuanhuang
 
> From: hadi@mojatatu.com
> Date: Thu, 2 Feb 2012 09:01:31 -0500
> To: wmwang2001@hotmail.com
> CC: jmh@joelhalpern.com; chuanhuang_li@mail.zjgsu.edu.cn; forces@ietf.org
> Subject: Re: [forces] IPv4prefix packing
>
> Hi Weiming,
>
> There are some implementation ties to what i described - but having fields being
> alignment accessible when it doesnt cost you anything is pragmatic. Reserved
> fields are a common occurrence in protocol and data definitions (we have one in
> the forces header for example for this very same reason).
>
> Sometimes it is hard to achieve that goal. For example when you have MAC
> addresses that straddle across 32 bit fields. In the Linux kernel,
> some equipment
> ends up adding 2B padding after the ethernet header after receiving the packet
> to align the IPv4/6 header so that when it is accessed, there are n o alignment
> penalties. So _how you send things on the wire_ makes a difference.
>
> In the same spirit of thought, but this one is not as a big deal,
> for EncapTableEntry, aligning on 32 bits:
>
> DstMac(32 bits)
> DstMac(16 bits): SrcMac (16 bits)
> SrcMac(32 bits)
> VlanID (16 bits): L2PortID(16 bits)
> L2PortID(16 bits)
>
> It would be nice maybe to have it as:
> DstMac(32 bits)
> DstMac(16 bits): SrcMac (16 bits)
> SrcMac(32 bits)
> VlanID (16 bits): Reserved (16bits)
> L2PortID(32 bits)
>
> Actually VlanID is 12 bits so the reserved could be reserved1(4 bits)
> and reserved2 (16bits)
>
> cheers,
> jamal
>
> On Tue, Jan 31, 2012 at 10:45 PM, Wang,Weiming <wmwang2001@hotmail.com> wrote:
> > Hi Jamal and Chuanhuang,
> >
> > I agree it seems like an implementation issue, whereas it als o seems a good way of optimization to the lib xml file, i.e., users may be rewarded  by the change at no extra cost.
> >
> > As a result, I suggest to make the component ID order as much as possible to consider the alignment for all LFBs.
> >
> > On the reserved field, I'm not sure if we now need this, or if we do so for all LFBs, the xml may look a little usual, with too many reserved fields?
> >
> > thanks,
> > Weiming
> >
> >
> > ----- Original Message -----
> > From: "Jamal Hadi Salim" <hadi@mojatatu.com>
> >
> > Aside from the packing issue, lets say your implementation was how i described
> > the most optimal layout out to be and you merely translated on where
> > to put things
> > as they come in from the wire with this format; on a lot of hardware,
> > the processing is going to consume  more cycles. For example, two fetches
> > will be required to retrieve HopSelector from the wire format.
> > So it is pragmatic to make this change.
> >
> > cheers,
> > jamal
> >
> > On Sun, Jan 15, 2012 at 11:33 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> >> I started out thinking exactly the way you describe Chuanhuang.
> >> Then Jamal pointed out to me that when one uses the full-data TLV we pack
> >> all of the data together. In order as defined by the LFB. At which point
> >> the alignment comes into play.
> >>
> >> Yours,
> >> Joel
> >>
> >>
> >> On 1/15/2012 9:10 PM, Chuanhuang Li wrote:
> >>>
> >>> Hi,Jamal
> >>> I have some different opinions.
> >>> I think the LFB definition is not a specific implementation. It just a
> >>> logical and
> >>> abstract definition. User can implement the LFB in different ways. But the
> >>> important
> >>> is that CE could use ForCES protocol to control these LFBs implemented by
> >>> different users.
> >>> Byte alignment is an implementation problem. If the reason for adding the
> >>> definition field is
> >>> just this one, from my point, i think we needn't change.
> >>>
> >>> Exactly, there may be other byte alignment cases, not just this one. For
> >>> example, if a "string" type
> >>> component is a member of "struct" type, such as the definition of
> >>> "LFBLinkType" in FEObject LFB.
> >>>
> >>> Yours,
> >>> Chuanhuang
> >>> ======= 2012-01-15 20:51:42 Jamal Hadi Salim, wrote: =======
> >>>
> >>>> Sorry, I didnt answer the core part of your question:
> >>>> We dont need this reserved field, but we want to annotate it
> >>>> so nobody tries to add a new field in the future; it is also
> >>>> common practise (look at evolution of many headers at IETF,
> >>>> IPv4, TCP etc).
> >>>>
> >>>> BTW: In the xml i sent you, I made a mistake in the IDs; i think ID=3
> >>>> is repeated twice.
> >>>>
> >>>> cheers,
> >>>> jamal
> >>>>
> >>>> On Sun, Jan 15, 2012 at 7:44 AM, Jamal Hadi Salim<hadi@mojatatu.com>
> >>>> wrote:
> >>>>>
> >>>>> Hi Chuanhuang,
> >>>>>
> >>>>> There are several reasons. One is: RAM is abused a lot more.
> >& gt;>>> Ive attached a small C program with four possible layouts of the fields.
> >>>>> In the suggested case we save 3Bytes compared to current definition.
> >>>>> Try running it to see what I mean. Then try to imagine you have 500K
> >>>>> such
> >>>>> fields and how much RAM you can save.
> >>>>> Not only for RAM, but if you were to send this structure on the wire -
> >>>>> the most efficient
> >>>>> way to do it is as i described. There is network equipment which will
> >>>>> do more than one
> >>>>> fetch to retrieve a field that goes across 32bit or 64bit alignment
> >>>>> boundaries; these
> >>>>> compute cycles could also be saved if you laid it out this way.
> >>>>> Third, to interop properly you cant send tha t struct with plain TLVs,
> >>>>> you need to
> >>>>> use ILVs (restricting its usefulness).
> >>>>>
> >>>>> cheers,
> >>>>> jamal
> >>>>>
> >>>>> On Sun, Jan 15, 2012 at 1:37 AM, Chuanhuang Li
> >>>>> <chuanhuang_li@mail.zjgsu.edu.cn> wrote:
> >>>>>>
> >>>>>> Hi,Jamal
> >>>>>> I think it's no problem that we add this reserved field, if it is
> >>>>>> needed sometime. But can you
> >>>>>> detailed the possible occasion to use this field? Thanks!
> >>>>>>
> >>>>>> Yours,
> >>>>>> Chuanhuang
> >>>>>> ======= 2012-01-14 21:59:17 Jamal Hadi Salim, wrote: =======
> >>>>>>> >>>>>>> The current IPV4 prefix is not efficient to send on the wire.
> >>>>>>> Can we re-arrange and add an 8 bit reserved field to make it more
> >>>>>>> efficient.
> >>>>>>> XML suggestions attached.
> >>>>>>>
> >>>>>>> cheers,
> >>>>>>> jamal
> >>>>>>>
> >>>>>>
> >>>>>>
> >>
> > _______________________________________________
> > forces mailing list
> > forces@ietf.org
> > https://www.ietf.org/mailman/listinfo/forces
> _______________________________________________
> forces mailing list
> forces@ietf.org
> https://www.ietf.org/mailman/listinfo/forces
--_47c18b6e-d5e9-477f-8c23-7e1132999220_-- --_7df6f95c-7a39-4e10-aac0-b62e291e4cd0_ Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VlanInputTable and EncapTable.txt" VmxhbklucHV0VGFibGVFbnRyeVR5cGU6DQogICAgICA8ZGF0YVR5cGVEZWY+DQogICAgICAgICA8 bmFtZT5WbGFuSW5wdXRUYWJsZUVudHJ5VHlwZTwvbmFtZT4NCiAgICAgICAgIDxzeW5vcHNpcz5F bnRyeSB0eXBlIGZvciBWTEFOIGlucHV0IHRhYmxlIGluIEV0aGVyQ2xhc3NpZmllciANCiAgICAg ICAgIExGQi48L3N5bm9wc2lzPg0KICAgICAgICAgPHN0cnVjdD4NCiAgICAgICAgICAgIDxjb21w b25lbnQgY29tcG9uZW50SUQ9IjEiPg0KICAgICAgICAgICAgICAgPG5hbWU+SW5jb21pbmdQb3J0 SUQ8L25hbWU+DQogICAgICAgICAgICAgICA8c3lub3BzaXM+VGhlIGluY29taW5nIHBvcnQgSUQu PC9zeW5vcHNpcz4NCiAgICAgICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4NCiAg ICAgICAgICAgIDwvY29tcG9uZW50Pg0KICAgICAgICAgICAgPGNvbXBvbmVudCBjb21wb25lbnRJ RD0iMiI+DQogICAgICAgICAgICAgICA8bmFtZT5WbGFuSUQ8L25hbWU+DQogICAgICAgICAgICAg ICA8c3lub3BzaXM+VmxhbiBJRC48L3N5bm9wc2lzPg0KICAgICAgICAgICAgICAgPHR5cGVSZWY+ VmxhbklEVHlwZTwvdHlwZVJlZj4NCiAgICAgICAgICAgIDwvY29tcG9uZW50Pg0KICAgICAgICAg ICAgPGNvbXBvbmVudCBjb21wb25lbnRJRD0iMyI+DQogICAgICAgICAgICAgICA8bmFtZT5SZXNl cnZlZDwvbmFtZT4NCiAgICAgICAgICAgICAgIDxzeW5vcHNpcz5SZXNlcnZlZCBmb3IgZnV0dXJl IHVzZTwvc3lub3BzaXM+DQogICAgICAgICAgICAgICA8dHlwZVJlZj51aW50MTY8L3R5cGVSZWY+ DQogICAgICAgICAgICAgICA8ZGVmYXVsdFZhbHVlPjA8L2RlZmF1bHRWYWx1ZT4NCiAgICAgICAg ICAgIDwvY29tcG9uZW50PiAgICAgICAgICANCiAgICAgICAgICAgIDxjb21wb25lbnQgY29tcG9u ZW50SUQ9IjQiPg0KICAgICAgICAgICAgICAgPG5hbWU+TG9naWNhbFBvcnRJRDwvbmFtZT4NCiAg ICAgICAgICAgICAgIDxzeW5vcHNpcz5sb2dpY2FsIHBvcnQgSUQuPC9zeW5vcHNpcz4NCiAgICAg ICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4NCiAgICAgICAgICAgIDwvY29tcG9u ZW50PiAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgPC9zdHJ1Y3Q+DQogICAg ICA8L2RhdGFUeXBlRGVmPg0KDQpFbmNhcFRhYmxlRW50cnlUeXBlOg0KICAgICAgPGRhdGFUeXBl RGVmPg0KICAgICAgICAgPG5hbWU+RW5jYXBUYWJsZUVudHJ5VHlwZTwvbmFtZT4NCiAgICAgICAg IDxzeW5vcHNpcz5FbnRyeSB0eXBlIGZvciBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uIHRhYmxlIGlu IA0KICAgICAgICAgRXRoZXJFbmNhcCBMRkIuPC9zeW5vcHNpcz4NCiAgICAgICAgIDxzdHJ1Y3Q+ DQogICAgICAgICAgICA8Y29tcG9uZW50IGNvbXBvbmVudElEPSIxIj4NCiAgICAgICAgICAgICAg IDxuYW1lPkRzdE1hYzwvbmFtZT4NCiAgICAgICAgICAgICAgIDxzeW5vcHNpcz5FdGhlcm5ldCBN YWMgb2YgdGhlIE5laWdoYm9yPC9zeW5vcHNpcz4NCiAgICAgICAgICAgICAgIDx0eXBlUmVmPklF RUVNQUM8L3R5cGVSZWY+DQogICAgICAgICAgICA8L2NvbXBvbmVudD4NCiAgICAgICAgICAgIDxj b21wb25lbnQgY29tcG9uZW50SUQ9IjIiPg0KICAgICAgICAgICAgICAgPG5hbWU+U3JjTWFjPC9u YW1lPg0KICAgICAgICAgICAgICAgPHN5bm9wc2lzPlNvdXJjZSBNQUMgdXNlZCBpbiBlbmNhcHN1 bGF0aW9uPC9zeW5vcHNpcz4NCiAgICAgICAgICAgICAgIDx0eXBlUmVmPklFRUVNQUM8L3R5cGVS ZWY+DQogICAgICAgICAgICA8L2NvbXBvbmVudD4NCiAgICAgICAgICAgIDxjb21wb25lbnQgY29t cG9uZW50SUQ9IjMiPg0KICAgICAgICAgICAgICAgPG5hbWU+VmxhbklEPC9uYW1lPg0KICAgICAg ICAgICAgICAgPHN5bm9wc2lzPlZMQU4gSUQuPC9zeW5vcHNpcz4NCiAgICAgICAgICAgICAgIDx0 eXBlUmVmPlZsYW5JRFR5cGU8L3R5cGVSZWY+DQogICAgICAgICAgICA8L2NvbXBvbmVudD4NCiAg ICAgICAgICAgICA8Y29tcG9uZW50IGNvbXBvbmVudElEPSI0Ij4NCiAgICAgICAgICAgICAgIDxu YW1lPlJlc2VydmVkPC9uYW1lPg0KICAgICAgICAgICAgICAgPHN5bm9wc2lzPlJlc2VydmVkIGZv ciBmdXR1cmUgdXNlPC9zeW5vcHNpcz4NCiAgICAgICAgICAgICAgIDx0eXBlUmVmPnVpbnQxNjwv dHlwZVJlZj4NCiAgICAgICAgICAgICAgIDxkZWZhdWx0VmFsdWU+MDwvZGVmYXVsdFZhbHVlPg0K ICAgICAgICAgICAgPC9jb21wb25lbnQ+ICAgICAgICAgICANCiAgICAgICAgICAgIDxjb21wb25l bnQgY29tcG9uZW50SUQ9IjUiPg0KICAgICAgICAgICAgICAgPG5hbWU+TDJQb3J0SUQ8L25hbWU+ DQogICAgICAgICAgICAgICA8c3lub3BzaXM+T3V0cHV0IGxvZ2ljYWwgTDIgcG9ydCBJRC48L3N5 bm9wc2lzPg0KICAgICAgICAgICAgICAgPHR5cGVSZWY+dWludDMyPC90eXBlUmVmPg0KICAgICAg ICAgICAgPC9jb21wb25lbnQ+DQogICAgICAgICA8L3N0cnVjdD4NCiAgICAgIDwvZGF0YVR5cGVE ZWY+IA== --_7df6f95c-7a39-4e10-aac0-b62e291e4cd0_-- From hadi@mojatatu.com Thu Feb 2 09:00:36 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0421F85F0 for ; Thu, 2 Feb 2012 09:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.641 X-Spam-Level: X-Spam-Status: No, score=-100.641 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_36=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpav3OhzKeEo for ; Thu, 2 Feb 2012 09:00:36 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E02A921F8646 for ; Thu, 2 Feb 2012 09:00:35 -0800 (PST) Received: by ghbg16 with SMTP id g16so1444589ghb.31 for ; Thu, 02 Feb 2012 09:00:35 -0800 (PST) Received: by 10.50.155.170 with SMTP id vx10mr13152299igb.22.1328202035214; Thu, 02 Feb 2012 09:00:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.68.142 with HTTP; Thu, 2 Feb 2012 09:00:15 -0800 (PST) In-Reply-To: References: <201201151437339009129@mail.zjgsu.edu.cn> <201201161010116180192@mail.zjgsu.edu.cn> <4F13A88B.20803@joelhalpern.com> From: Jamal Hadi Salim Date: Thu, 2 Feb 2012 12:00:15 -0500 Message-ID: To: Chuanhuang Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jmh@joelhalpern.com, chuanhuang_li@mail.zjgsu.edu.cn, forces@ietf.org Subject: Re: [forces] IPv4prefix packing X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 17:00:36 -0000 2012/2/2 Chuanhuang Li : > Hi, Jamal and all > =A0=A0=A0=A0 If we consider the alignment issue, besides the type of IPv4= Prefix, > IPv6Prefix and > EncapTable, VlanInputTable in EtherClassifier also need to be modified. T= he > way to solve > alignment with adding Reserved field, please see the attachment. I think this is fine - Note: I dont feel as strongly about this as i did about the ipv4 prefixing. > I agree to Jamal's modification suggestion.=A0 But, i still think this is= just > an FE's implementation issue. > The main goal=A0of LFB definition is that=A0CE can control and configure = FEs > implemented by different users, not > guiding=A0user to implement an FE. > The alignment said in ForCES protocol and the aligment in FE's > implementation are two different issues. > If user sends ForCES message with TLV length not multiple of 32 bits, > Padding is required. > Whatever the LFB is defined, this requirement can be reached. But the LFB > can be implemented in different ways. > For example, the "SupportedLFBType" defined in FEObject LFB, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SupportedLFBType > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 table entry for s= upported LFB > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LFBName > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The name = of a supported LFB class > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 string= > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LFBClassI= D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the i= d of a supported LFB class > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 uint32= > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ...... > LFBName is string type, LFBClassID, uint32 type, respectively. > User can implement this type in the following way: > typedef struct SupportedLFBType{ > =A0=A0=A0=A0=A0=A0=A0 UINT8=A0=A0=A0 LFBName[FEOBJECTLFB_MAX_STRING_LENGT= H]; > =A0=A0=A0=A0=A0=A0=A0 UINT32=A0=A0 LFBClassID; > =A0=A0=A0=A0=A0=A0=A0 ...... > The macro "FEOBJECTLFB_MAX_STRING_LENGTH" used by LFBName can be any valu= e > that user wants to use > (for alignment, Usually be multiple of 32 bits). > But if user encapsulates the information into TLV, the string length is t= he > actual length > of the value. It is not multiple of 32 bits in most cases. Strings are easy. You have no choice but to pack variable sized entities(like strings) in TLV or ILV. In the case the string size is not 32-bit aligned, xLV must be padded to be 32-bit aligned. So accessing the on-the-wire format is alignment friendly. Imagine instead of a string you have a uint8 in the place of LFBName; then the issue is clear. cheers, jamal From internet-drafts@ietf.org Mon Feb 20 13:45:10 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC9521F859E; Mon, 20 Feb 2012 13:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+cABdUSOC-S; Mon, 20 Feb 2012 13:45:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9521F852A; Mon, 20 Feb 2012 13:44:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120220214449.23072.22476.idtracker@ietfa.amsl.com> Date: Mon, 20 Feb 2012 13:44:49 -0800 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-ceha-03.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:45:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separa= tion Working Group of the IETF. Title : ForCES Intra-NE High Availability Author(s) : Kentaro Ogawa Weiming Wang Evangelos Haleplidis Jamal Hadi Salim Filename : draft-ietf-forces-ceha-03.txt Pages : 25 Date : 2012-02-20 This document discusses CE High Availability within a ForCES NE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-ceha-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-forces-ceha-03.txt From internet-drafts@ietf.org Tue Feb 28 19:01:12 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30FA21E803D; Tue, 28 Feb 2012 19:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s4w1rU+UZ1n; Tue, 28 Feb 2012 19:01:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFFA21E8021; Tue, 28 Feb 2012 19:00:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120229030052.18109.5895.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 19:00:52 -0800 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-lfb-lib-08.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 03:01:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separa= tion Working Group of the IETF. Title : ForCES Logical Function Block (LFB) Library Author(s) : Weiming Wang Evangelos Haleplidis Kentaro Ogawa Chuanhuang Li Halpern Joel Filename : draft-ietf-forces-lfb-lib-08.txt Pages : 113 Date : 2012-02-28 This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-lfb-lib-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-forces-lfb-lib-08.txt