Subject: [manet] DYMO Unknown Type Handling Bits

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 7 Jun 2006 08:47:35 -0700

I'd like to solicit some discussion on the use of unknown type handling bits.

In DYMO (and DSR before that) there are several bits that indicate the
way the information associated with an unknown type should be handled.

Currently in DYMO there are three ways to process unknown types
1) ignore that the information exists and process all known information
2) ignore the unknown information type and remove it from the
information that gets propogated
3) discard the message

If you are currently using DYMO or expect to use DYMO in the future,
please email the list with a few paragraphs describing why this
functionality is important to you.

Thanks,
Ian Chakeres

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 07 Jun 2006 18:50:04 -0700

Hello Ian,

There is an useful functionality missing on this list, that was present
in previous DYMO drafts.  Namely, we had a bit in the main header
that indicated whether a node had ignored an extension.  This would
be useful for a recipient to determine whether the processing for
some extension was (relatively) exact or not.   Cases that come to
mind include various extensions to measure parameters that could
be used for quality of service, as well as potentially making better
recovery of topology information when not all nodes are participating.

The point of making a specification for handling unknown types is
for better handling in networks where not all nodes can do the
processing for a future extension.  This is tricky because clearly
we cannot foresee all future scenarios, and yet we have to try to
provide for them in some economical fashion. I think that allocating
this one bit for the stated purpose is a good tradeoff and could very
well make the difference for allowing deployment of future new
features in mixed networks.

Regards,
Charlie P.