Subject: [manet] Comments on NHDP Draft

From: "Joseph Kopena" <[email-masked]>
Date: Tue, 11 Sep 2007 13:44:03 -0400

Hi all,

The following are a few comments on NHDP draft 4.

Thx!

-------
[ Content ]

PacketBB specifies that the orginator address is optional.  NHDP does
not seem to say anything about this, and it perhaps should.
"Originator address" is referred to several times in the document,
without (as far as I can see) specifying where that value is coming
from or than it must be included in the message header.  I don't think
having an explicit PacketBB message-hdr-info originator address
actually matters as long as everything in the NHDP spec &
implementation is based around addresses in the received Local
Interface Block rather than an "originating node."  Looking through,
some of the discussion of "Removed Address List" in Section 9.2 may
have to be reworded a bit.

It might be worth noting quickly in 10.1.1 that it is safe to rely on
the ordering of the address blocks, for example that the first block
is the Local Interface Block, even in the presence of integration with
other protocols or piggybacking data, because they will all be in
other PacketBB messages within the packet.  That's not obvious without
being familiar with PacketBB, and can lead to some concern.  I would
still slightly consider not relying on the ordering and instead
explicitly marking those addresses as local interfaces.  That burns
extra bits, but it sounds cleaner, safer, and marginally easier to
work with depending on the PacketBB implementation in use.

Much of the quality discussion seems somewhat vacuous.  It's not clear
why the information bases are mandated by the spec to include quality
information when it's not used by NHDP and there's a good chance the
quality framework won't be used, at least as-is, by implementations.
A dimensionless number from 0--1 doesn't seem to quite cut it.  For
example, that doesn't allow for using expected throughput as a measure
of quality.  The quality support should be generalized a bit or punted
entirely to implementations, possibly with the current material presented
more clearly as guidance or an option, and perhaps in an appendix.

[ Typographical Notes ]

pg 18: "A MANET interface... and as of a symmetric 2-hop neighbor."
should be "A MANET interface... and as a symmetric of another node."
(the "of" is a typo, and the wording of the second clause doesn't
quite match the first)

pg 22: "... and the node will longer participate..." should be
"... and the node will no longer participate..."

pg 29: "... Local Interface Block is one of its interface
addresses..."  should be "... Local Interface Block is one of the
node's own interface addresses..."  just to be totally explicit on who
"one of its" refers to.

pg 23, paragraph on this protocol specifying three TLVs: This could
perhaps be shortened by simply using fulltype as defined by PacketBB,
but it's not a big deal either way.
-------

-- 
- joe kopena
  stay on target

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

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 10:08:56 +0100

> The following are a few comments on NHDP draft 4.

Thanks for these.

> not seem to say anything about this, and it perhaps should.

Looking at the text in sections 9.2 and 9.4, they do need modification,
or the insertion of a piece of text somewhere else. They refer to a
concept, that using an interface address as an originator address is a
good, but not mandated, mechanism that is missing from the draft.
(I'm sure that text existed at some point, possibly before NHDP was
separated from OLSRv2, but isn't there now.)

> work with depending on the PacketBB implementation in use.

And here we get into the classic argument that some are happy to burn
bits, and others aren't. (I sit in the "sometimes yes, sometimes no"
position.) I think relying on the ordering is OK, but it is worth
considering whether constraints on modifying NHDP messages should be
explicitly stated, maybe in an appendix. One to think about.

> information when it's not used by NHDP

Yes it is. It's not mandated that it be used, but it is specified how
it is used. (Equivalently, it can be considered always used, but
implementations that set L_quality = 1 and leave it there can be
simplified.)

> and there's a good chance the quality framework won't be used,
> at least as-is, by implementations.

It will be by several.

> A dimensionless number from 0--1 doesn't seem to quite cut it.

Bearing in mind that what you are doing is comparing it with two
thresholds, a dimensionless number works fine. Anything that is
monotonically increasing works fine. A dimensionless number moves
the "what actual physical value should I use?" question outside
NHDP to the implementation-specific region where it belongs.

Furthermore there are implementations of OLSR, especially those
running over 802.11 systems, that use this, and don't work without
it. On the IETF philosophy of "running code" this passes with
flying colours.

And that's the key reason for it. Since running over 802.11 is
a "must support" case (without, of course, being specified, or
even privileged) what we currently have is a protocol (OLSR) which
as defined (RFC 3626) can be implemented as described in the
specification so as to work. Having a specification (here the
NHDP part of OLSRv2) that is a successor to it, but is inferior
in that each implementor has to invent his own mechanism to
extend the published protocol to get something that works just
isn't acceptable.

(As for why things don't work over 802.11 without some such
mechanism, see the literature on the 802.11 "grey zone".)

> For
> of quality.

If you actually want to use expected throughput as a measure of
quality in the sense used in NHDP (which is not a QoS sense, it's
a "don't use bad links" sense) there's no reason you can't map that
to a normalised value. If you want to use expected throughput in a
more sophisticated way, that's a separate issue (and the recent
metrics discussion is more appropriate - and that's an separate
mechanism that would exist alongside this).

> (the "of" is a typo, and the wording of the second clause doesn't

Not quite. It's not an elegant sentence, and may well be better
reworded, but "of" is not a typo. What is a typo is that "in both"
should be "both in".

> "... and the node will no longer participate..."

Yes.

> node's own interface addresses..."  just to be totally explicit on who

Agreed. I might drop the "own".

> but it's not a big deal either way.

Worth a thought. Thank you.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Joseph Kopena" <[email-masked]>
Date: Wed, 12 Sep 2007 10:34:21 -0400

> mechanism that would exist alongside this).

Hi Christopher,

I agree that the current quality framework is pretty reasonable &
realize it's used in OLSR and other places.  I just don't think it
necessarily needs to be specified in NHDP.

For example, it's not totally obvious how to normalize expected
throughput, even for simple ways.  On 802.11b, do I assume the cap is
the "advertised" max data rate on the network, e.g. 1 or 11Mbps, or
the actual in-practice maximum, e.g. ~5Mbps for 11Mbps cards.  What if
a node is on several network types with very different data rates?
The quality ratings will either be squashed, with a loss of precision
in differentiating links on the same network, or incomparable &
requiring extra work to only compare apples against apples.

I agree the metrics discussion is the place for this kind of thing, so
why not move the whole quality discussion to there?  NHDP doesn't seem
to actually require saying much about how quality is reasoned on.  For
example, instead of specifying that links are lost when they fall
below a predetermined quality threshold, it could simply say that
links are marked as lost when determined to be unusable by the NHDP
implementation.  If people want to use the 0..1 metric, that's fine.
If they want to use something else, such as expected throughput or
another characteristic from the metrics discussion, then that's fine
as well.

The given metric is very practical & usable, it just doesn't seem that
support for it has to be mandated here.  I also realize that it's not
really a big deal for implementors to sidestep the quality framework
and do their own thing, but then why include it in the spec?

Thx!

-- 
- joe kopena
  right here and now

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 15:44:25 +0100

NHDP is part of OLSRv2, specifically the part which
includes this functionality. So if it's needed in OLSR,
and hence in OLSRv2, it's needed in NHDP.

And it is needed separately from metrics (which may or
may not be added). Metrics may improve performance.
Something like this, which is needed to make OLSR(v2)
work for 802.11 networks, but is simpler isn't an
optional inclusion in the specification.

Or in other words, OLSRv2 must be better than OLSR.
Without this, it's worse in an important regard, and
that's not acceptable.

-----Original Message-----
From: Joseph Kopena [mailto:[email-masked]] 
Sent: 12 September 2007 15:34
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Comments on NHDP Draft

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Hi Christopher,

Thx!

-- 
- joe kopena
  right here and now

---

From: Brian Adamson <[email-masked]>
Date: Wed, 12 Sep 2007 10:59:08 -0400

Chris,

I think it would be possible for OLSRv2 to specify extensions to NHDP 
that it specifically needs.  The NHDP base spec could remain more 
independent this way.

I do think that quality/metrics/etc sharing and even determination 
will be an application of NHDP in many different protocols, but the 
specifics of those details could be specified as extensions (with 
appropriate TLVs, etc) to the NHDP base specification.

I think the basic signaling of neighbor presence/status that NHDP 
provides is an important core.  Adding quality information (metrics) 
to NHDP could be accomplished separately?

-- 
Brian
__________________________________
Brian Adamson
<mailto:[email-masked]>

---

From: "Joseph Kopena" <[email-masked]>
Date: Wed, 12 Sep 2007 11:04:56 -0400

> to NHDP could be accomplished separately?

I agree & don't necessarily see NHDP as part of OLSR.  If that's true,
it should be in the OLSR spec.  My reading of NHDP is that it provides
core functionality needed by many protocols, for example SMF needs
this functionality.  One of the core attractions to me of NHDP is that
not only can one spec cover this piece of functionality, but combined
with PacketBB & appropriate implementation you could have one process
providing this service to several other protocols, as well as allowing
for piggybacking data.  If OLSR uses specific quality metrics, that
should be part of the OLSR spec, not necessarily NHDP's.

Thx

-- 
- joe kopena
  right here and now

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 16:05:33 +0100

It is theoretically possible not to put it in NHDP,
but it's very, very messy, because you have to put
into OLSRv2 either a modification of an algorithm
that's in NHDP (and things of the form "before step
2.1 of section x.y.z add this step 2a" are horrible)
or re-write out the whole things again in OLSRv2,
which is another bad idea.

Furthermore, the reasons why it's needed apply
equally well to NHDP.

Please note that we are NOT talking about metrics.
Metrics would be added to OLSRv2 not NHDP (as the
draft on adding them says). This is the mechanism
that is used for (e.g.) 802.11 grey zone handling,
is much simpler, and is appropriate to NHDP, as
it's about L2 (or anywhere else" information
over-riding the HELLO-based information to use
a link.

-----Original Message-----
From: Brian Adamson [mailto:[email-masked]] 
Sent: 12 September 2007 15:59
To: Dearlove, Christopher (UK); Joseph Kopena
Cc: [email-masked]
Subject: RE: [manet] Comments on NHDP Draft

               *** WARNING ***

Chris,

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 16:13:03 +0100

NHDP only exists because we, the OLSRv2 authors (which
90+% means Thomas and I) took the time and trouble to
separate it out from OLSRv2 into a separate specification.
It is absolutely unacceptable for people to then say it
isn't part of OLSRv2, and shouldn't include what we need
in it.

Frankly the same applies to packetbb, jitter and timetlv.
I believe that we have compromised the timeliness of getting
OLSRv2 out in the interests of community spirit and doing the
right thing. And it's been an almost one way street where we
give and others take. (For example until we separated NHDP out,
SMF had a very messy version of this, lifted from an already
out of date OLSRv2, with known errors.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph
Kopena
Sent: 12 September 2007 16:05
To: Brian Adamson
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] Comments on NHDP Draft

               *** WARNING ***

Thx

-- 
- joe kopena
  right here and now

---

From: "Joseph Kopena" <[email-masked]>
Date: Wed, 12 Sep 2007 11:33:26 -0400

> which is another bad idea.

I don't think it would be so bad.  It seems to me that NHDP, rather
than specifying quality variables and threshold comparisons for making
decisions on things like symmetric links, can simply stipulate a set
of functions for making those decisions.  The OLSR spec then simply
has to define those functions.

> Metrics would be added to OLSRv2 not NHDP (as the

But if NHDP is making decision about links, and it is in marking links
as lost or symmetric, then it needs to potentially support a variety
of metrics.

> isn't part of OLSRv2, and shouldn't include what we need

And that was the right move to make & is much appreciate & will save
everyone time, but forcing elements needed by OLSR into NHDP and
trying to make it a sub-spec of OLSR does your own work a disservice.
If you work to make it less usable by other protocols and
implementations, for example by specifying a quality framework used by
OLSR but not necessarily others, then you may as well have kept it
simply a chapter in the OLSR spec.

Thx

-- 
- joe kopena
  right here and now

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 16:50:48 +0100

> forcing elements needed by OLSR into NHDP and

I believe this completely mischaracterises the situation.

The mechanism is in NHDP because it is fundamentally
part of that part of the protocol. Roughly speaking,
HELLO messages determine whether a link may be used.
But we may have additional information that specifies
whether the link should be used i.e. whether a node
should be considered a neighbour (i.e. the N of NHDP).
Furthermore there are scenarios that need it - 802.11
grey zones. If I were using NHDP separate from OLSRv2
I would still have need for a mechanism to over-ride
the HELLO message based solution. That is, there are
sound NHDP, as well as OLSRv2, reasons for it.

The mechanism given is abou the simplest there can be.
the abolutely simplest is two state - use it if HELLOs
say so vs. don't use it even if they say so. But we
know that two-state solutions lead to instability, hence
a tri-state solution with hysteresis - although if you
want a two-state solution set the two thresholds equal.
And if you don't want anything just set L_quality high
and the thresholds low. (And if your implementation only
does that, simplify it, it's still compliant.)

If you have a complicated algorithm to decide whether
to use it, you can map it to this one as a "how to set
L_quality" process.

Where I would have agreed with you is had you said that
the specific leaky integrator used in RFC 3626 was too
specific. But you will note we did remove that (or not
put it in).

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Sep 2007 11:26:47 -0700

Hello Chris,

I was _very_ surprised to read this:

ext Dearlove, Christopher (UK) wrote:
> It is absolutely unacceptable for people to then say <NHDP>

 While I agree that the [manet] neighbor discovery protocol
should include what is needed for OLSR to work, I can't imagine
agreeing that it is "part" of OLSRv2.

I thought we had been assured that any routing protocol,
including DYMO, would be able to use NHDP.

Should we re-start with a new neighborhood discovery document
that is NOT part of OLSRv2?

> Frankly the same applies to packetbb, jitter and timetlv.
 Are they also part of OLSRv2?  If so, then they ought to be renamed.
For instance, we could have:
    "Jitter considerations in MANETs using OLSRv2".

I was worried before, but now I a lot more worried.
 
Regards,
Charlie P.

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 12 Sep 2007 15:21:09 -0400

I agree with Brian's comments, the philosophy I felt the WG supported was a common core.

> Sent: Wednesday, September 12, 2007 10:59 AM

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 13 Sep 2007 09:33:01 +0100

And link quality usage of the limited form specified
is part of that common core. Note that this is NOT
about link metrics, it's about the most basic "do you
have L2 - or any other - information to over-ride the
HELLO message exchange that suggests the link is
usable". It's an essential component for NHDP to work
on some systems (e.g. 802.11), bearing in mind that
you can map anything to it.

It is clear that people are confusing this with link
metrics. That, I agree is out of place in NHDP, and
there are no suggestions to put that into NHDP.

-----Original Message-----
From: Joe Macker [mailto:[email-masked]] 
Sent: 12 September 2007 20:21
To: 'Brian Adamson'; Dearlove, Christopher (UK); 'Joseph Kopena'
Cc: [email-masked]
Subject: RE: [manet] Comments on NHDP Draft

               *** WARNING ***

I agree with Brian's comments, the philosophy I felt the WG supported
was a common core.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 13 Sep 2007 09:33:42 +0100

> agreeing that it is "part" of OLSRv2.

Of course it's part of OLSRv2 - it's a normative inclusion
in the OLSRv2 specification, which won't work without it.

That's aside from the history of how it came to be written,
spun off from OLSRv2.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Sep 2007 08:36:28 -0700

Hello Chris,

> in the OLSRv2 specification, which won't work without it.

 ... By this logic, IPv6 is "part of" DHCPv6.  I sincerely believe that
DHCPv6 will not work without IPv6, and it is a normative citation.
Perhaps OLSRv2 should cite RFC 791 so that the whole Internet
can be "part of" OLSRv2.

In normal conversation, such phraseology means that that
one protocol is subordinate to the other one.  That should not
be true in this case.

Up until now, I have not been a big fan of problem statements
and requirement statements and so on.  But if there is danger
that NHDP cannot stand alone without consideration for the
specific needs of OLSRv2, then I might change my mind.  As
another example, SMURF was designed so that it could, in
theory, be used by OLSR, AODV, DYMO, DSR, and
TBRPF.  That document would need to evolve to handle
certain (rare) cases that NHDP does better, but the evolution
would be simple to do.

If it would be helpful, I could devise a problem statement and
requirements document that would serve the general needs of
typical proactive, reactive, and hybrid protocols.  The base
protocol should also be extensible to allow for needed features
related to neighborhood discovery that may be of use in
particular systems.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 13 Sep 2007 16:54:32 +0100

That's stretching things to a silly point.
NHDP is fundamental to OLSRv2, and that's
how we (the OLSRv2 design team) designed it.

(In fact RFC 791 is NOT fundamental to OLSRv2,
apart from that we can also support IPv6, we
could actually support anything with fixed length
identities.)

We did our job well enough that it can be used
outside OLSRv2. It's not going to all jobs outside
OLSRv2, but it covers quite a few. We've already
made modifications to cover more than we originally
suggested (the greatly enhanced how to use outside
information material - which led to the contraints
on modification of the information base for example)
and I don't exclude other minor changes.

But the whole "let's now start with a problem
statement" is not living in the real world. Let me
quote from the MANET WG charter

Dec 2006    Submit PacketBB to IESG  
Apr 2007    Submit NHDP to IESG  
Apr 2007    Submit OLSRv2 to IESG  

We're already running late, and time is money. I see
no reason not to proceed with the documents essentially
as they are (I know of a couple of minor tweaks needed)
and get them all to the IESG before Vancouver.

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 13 September 2007 16:36
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Comments on NHDP Draft

               *** WARNING ***

Hello Chris,

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 13 Sep 2007 17:45:31 +0100

> I see no reason not to proceed with the documents essentially

Let me make a small correction to myself. Except OLSRv2 if we
decide to add metrics to it.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Sep 2007 09:54:02 -0700

Hello Chris,
 
> how we (the OLSRv2 design team) designed it.

 Your statement is making me even more worried.
Let me try an alternative formulation.  If you can agree
with it, then there is less cause for concern.

   For many reasons, e.g., saving congestion and power
   consumption, it is beneficial for nodes to identify
   a subset of their neighboring nodes as relay points for
   signaling messages that require flooding to larger
   regions of the network beyond the local neighborhood.
   There are many algorithms by which neighbors may be
   identified as relay points.  Of these algorithms, many
   work by enabling each node to collect data on the
   two-hop neighborhoods for each of its network
   interfaces.   The [manet] Neighbhood Discovery
   document specifies a protocol by which this two-hop
   information may be collected in an efficient manner.
   This two-hop information can then be used by the
   algorithms for selecting relay nodes.  Once this is
   done, the relay node structures created can be used
   by protocols for which flooding is an important
   operation, including OLSRv2 and DYMO.

If we focus the Neighborhood Discovery on collecting
the relevant data about local neighborhoods (!!), then I
reckon the result will be as desired.  And I think it can
be understood on its own merits -- not only as a "part"
of some higher-level protocol.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 13 Sep 2007 18:05:15 +0100

I am totally happy with your formulation. (In fact when
we next update NHDP I will, with your permission, check
to see if any of it says things better than the corresponding
part of the existing preamble.)

But I don't see that as opposed to my comments, but
complementary to it, two ways of looking at the same
set of facts. (I want to look at it both ways.)

The only place that I can see someone nit-picking is that
it's also possible to use NHDP if you are only interested
in one hop neighbours, not two. There is in that case no
point in collecting the 2-Hop Set, but the signalling can
be unchanged. (With multiple interfaces you can drop the
addresses flagged as OTHER_NEIGHB, but you don't need to.)
I don't recall off the top of my head if this point is
made in the current version or not, I think it is, but I
may be wrong. (This may be a reason why we don't end up
borrowing your words. But I'd like to have the option.)

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 13 September 2007 17:54
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Comments on NHDP Draft

               *** WARNING ***

Hello Chris,

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Sep 2007 10:08:29 -0700

Hello again Chris,

ext Dearlove, Christopher (UK) wrote:
>   ....    I see

PacketBB needs to have section 5.3.2 removed.  I guess that
is a minor tweak, since it is not germane to the main point of the
specification.  I have made one or two other small suggestions
for improvement that I did not see in the latest document, but
by my estimation they are also minor tweaks.

NHDP is, as I have pointed out, far too bloated as is.  I hope
we can go forward with some leaner alternatives, at least as
optional TLVs oriented towards networks with realistic nodal
degrees.  I do not think that is a minor tweak.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 13 Sep 2007 18:13:01 +0100

Unfortunately after the agreement on your last point,
I (and not just I) disagree with both of your two points here
- 5.3.2 not only does not need to go, it needs to stay.
- I totally disagree with your chracaterisation of NHDP.

I was, and am, referring to going ahead without those
changes.

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 13 September 2007 18:08
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] Comments on NHDP Draft

               *** WARNING ***

Hello again Chris,

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Sep 2007 10:12:49 -0700

Hello Chris,

> part of the existing preamble.)

I am delighted that you agree with the formulation, and you
are more than welcome to use it in any way.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Sep 2007 16:28:40 -0700

Hello Chris,

I want to get to a good resolution of this issue.
First let me excerpt one of your recent emails.

When discussing the role of section 5.3.2 and
the language detailing  how unexpected packet
conditions are handled, you stated:
> ... that is exactly what the specification does,
> it leaves it up to the protocol.
... in other words, packetBB leaves the handling for
unexpected packet conditions up to each individual
protocol that is written to conform to packetBB.
This is fine with me.

Perhaps we can agree that for some protocols,
it is useful for TLVs to be ordered, and for some
protocols it is not useful.   I fully expect there could
be some of the first kind, and a protocol that I
want to offer for working group consideration is
an example of the second kind.

With this in mind, I will offer a revised version of
section 5.3.2 that may be mutually satisfactory.

======================================

5.3.2:  TLV ordering constraints.

For some protocols, it is important that some or
all TLVs be sorted in nondecreasing numeric order.
It is part of the individual protocol specification
to indicate that TLVs are expected to be ordered.

Protocols can specify the following conditions:
- TLVs in the same TLV block MUST be sorted in
   non-descending tlv-fulltype order.

-  Packet and message TLVs MUST be defined so as to indicate whether two
   TLVs with the same tlv-fulltype are, or are not, allowed in the same
   packet or message TLV block, respectively.

-  Two or more TLVs with the same tlv-fulltype in the same address block
   TLV block MUST NOT be associated with the same copy of an address
   (i.e. they must not have overlapping index ranges).

-   TLVs with the same tlv-fulltype associated with the same address
   block MUST be sorted in ascending index-start order.

When these conditions are specified for ordering of various
TLV blocks, then nonconforming packets must be flagged as
malformed.  When a packet is to flagged as malformed, the
considerations of section 5.3.3 apply. 

==============================================

I hope you will find this revised version of section 5.3.2 to be
satisfactory for those protocols that need the ordering
constraints.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Fri, 14 Sep 2007 09:21:04 +0100

I'm sorry, no. This essentially balkanises packetbb
into more than one structure. THere are major savings
that arise from having these constraints, and you can
write appreciably simpler code with them. This gets
you the worst of all worlds if you want generic packetbb
code.

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 14 September 2007 00:29
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Discussion about packetBB ordering constraints -- a way
forward?

Hello Chris,

Regards,
Charlie P.