Subject: FW: [manet] packetbb constraints

From: "Justin Dean" <[email-masked]>
Date: Mon, 17 Sep 2007 17:27:50 -0400

After some more thought and discussions.  Here is a proposal for a way
forward with regards to TLV ordering.  Define 3 name spaces FRONT, MIDDLE,
END for TLVs where FRONT TLVs are always before MIDDLE which are always
before END.  FRONT and END spaces must be ordered as defined in protocols,
MIDDLE TLVs have no ordering requirement other than after FRONT and before
END.  In packetbb mandate that protocols MUST define which space the TLVs
defined in them fall under, and if they are FRONT or END an ordering within
that space.  TLVs which fall outside of the protocol space (packet TLVs)
must have a defined ordering with regard to other packet TLVs.  Any protocol
derived from other protocols MUST define how they interact if at all with
other derived protocols and the ordering restrictions. 

This will supply an order to important TLVs as protocols require, allow for
flexibility later on, and guarantees protocols needing order that their TLVs
will come before unordered TLVs.  The draw back is maintaining a list of
orders both in a document and within implementations.  For packet TLVs it
may even be useful to divide the type space so implementations will know
which space the TLVs are falling into without having to have the most up to
date list of packet TLV types.

Justin

> -----Original Message-----
> From: Justin Dean [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 12:36 PM
> To: 'Brian Haberman'
> Cc: 'manet'
> Subject: RE: [manet] packetbb constraints
> 
> I agree with a lot of what you have said here.  I posted the 
> example more to point out that there are protocols which have 
> ordering (and with hop-by-hop options mandated ordering) 
> considerations and not to make a direct comparison.  Although 
> since they were raised a few comments in line. 
> 
> > -----Original Message-----
> > From: Brian Haberman [mailto:[email-masked]]
> > Sent: Monday, September 17, 2007 11:11 AM
> > To: Justin Dean
> > Cc: 'Charles E. Perkins'; 'manet'
> > Subject: Re: [manet] packetbb constraints
> > 
> > Justin,
> >       I am a little confused with your text below.  You start by 
> > mentioning IPv6 Option Headers and immediately quote text 
> on extension 
> > headers.  The interesting text on extension headers is found in 
> > Section
> > 4.1 or RFC 2460, which states:
> > 
> >     When more than one extension header is used in the same 
> packet, it 
> > is
> >     recommended that those headers appear in the following order:
> > 
> >             IPv6 header
> >             Hop-by-Hop Options header
> >             Destination Options header (note 1)
> >             Routing header
> >             Fragment header
> >             Authentication header (note 2)
> >             Encapsulating Security Payload header (note 2)
> >             Destination Options header (note 3)
> >             upper-layer header
> > 
> > Please note the use of recommended in this text.  It is not 
> a hard and 
> > fast rule.
> > 
> I actually suggested having an ordering independent of the 
> type value fields much the same way IPv6 proposes.  Ordering 
> is not hard and fast rule with
> IPv6 and processing in order is mandated.  I would rather 
> mandate ordering and allow for any kind of processing. 
> 
> > Further along, the section points out the following:
> > 
> >     If and when other extension headers are defined, their ordering
> >     constraints relative to the above listed headers must be 
> > specified.
> > 
> > This allows future extensions to be added and their 
> position described 
> > relative to the recommended order.  The most interesting 
> point, IMHO, 
> > is the last part of the section which states:
> > 
> 
> I am warming to this method for ordering although in my 
> opinion it has the need for the following restriction.
> 
> >     IPv6 nodes must accept and attempt to process extension 
> headers in
> >     any order and occurring any number of times in the same packet,
> >     except for the Hop-by-Hop Options header which is restricted to
> >     appear immediately after an IPv6 header only.  
> Nonetheless, it is
> >     strongly advised that sources of IPv6 packets adhere to 
> the above
> >     recommended order until and unless subsequent specifications 
> > revise
> >     that recommendation.
> > 
> 
> This rule is really required when ordering is not mandated or 
> can be changed by later specifications.  I my opinion this is 
> drawback to IPv6's method as all orders must be accepted, 
> limiting processing optimizations.  Receivers don't actually 
> KNOW a TLV isn't there until the end of the TLV block.
> 
> > This rule allows IPv6 to be liberal in what it receives in order to 
> > support implementations that did not follow the recommended 
> ordering 
> > mentioned earlier.
> > 
> > Regards,
> > Brian
> > 
> 
> In summary if we were to do a packetbb ordering setup similar 
> to IPv6 I would not be in favor of forced processing and any 
> ordering but the exact opposite or any processing and a fixed order.
> 
>    Therefore, extension headers must
>    be processed strictly in the order they appear in the packet; a
>    receiver must not, for example, scan through a packet looking for a
>    particular kind of extension header and process that 
> header prior to
>    processing all preceding ones.
> 
> Justin
> 
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> 

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Russ White <[email-masked]>
Date: Tue, 18 Sep 2007 11:34:11 -0400

> date list of packet TLV types.

Why three sections, though? Why not a number space that is guaranteed to
be in order, and another number space that is not guaranteed to be in
order? That would make processing, on both the building the packet end
and on processing end, much simpler. And I would make it a requirement
that all new TLVs be placed in the unordered space unless it can clearly
be shown that the ordering is critical to protocol operation.

Ordered TLVs can add a good bit of complexity to implementations, IMHO,
and we should avoid them wherever possible.

:-)

Russ