Subject: [manet] Forwarding on packetbb <msg-header> only & MANET_ID TLV

From: "Teco Boot" <[email-masked]>
Date: Wed, 14 Nov 2007 08:50:23 +0100

Hi,

After private discussions and reading I-Ds over and over again, I still do
not agree on PacketBB text on forwarding, based on message-header only:
<...start...>
   o  A message header format, which may allow a node to make
      praocessing and forwarding decisions based on the node's present
      state and the message header, without inspecting and parsing the
      message body.  Message header information permits single- and
      multi-hop message diffusion.
<...>
   Separation of forwarding and processing  - duplicate detection and
      controlled scope message forwarding decisions can be made using
      information contained in the message header, without processing
      the message body.
<...>
   Message  - the fundamental entity carrying protocol information, in
      the form of addresses and TLVs.  Messages are transmitted in
      packets, and may be forwarded based on their header information.
<...>
   o  Messages are designed to be carriers of protocol information and
      MAY, at each hop, be forwarded and/or processed according to the
      information in the message header by the protocol using this
      specification.
<...end...>
A MANET Router MAY NOT forward messages that contain TLV that are not
understood, e.g. are defined for routing protocols that are not active on
this MANET Router. Or contain TLV that are well understood but limit
forwarding.

Let's use MANET_ID as example (draft-chakeres-manet-manetid-00.txt). I think
it is unacceptable that information form region X leaks into region Y, Z,
AA, .... ZZZZZ. Maybe it is not processed and not that harmful, but it is a
waste of bandwidth. I can imagine much more evil examples, I used MANET_ID
as I like this idea.

Bytheway, can we discuss Ian's MANET_ID I-D in Vancouver? Agenda:
<...>
?. Individual Submissions
<...>
     <wg-chair-hat-off chair="Ian Chakeres">
     * MANET Region ID TLV (Ian Chakeres, 5 min) - NEW
     http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-00.txt
     </wg-chair-hat-off chair="Ian Chakeres">
<...>

Cheers, Teco

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Nov 2007 09:34:22 -0000

The paragraph that Teco quotes says that this _may_
allow a node to make such a decision. That's all.
How processing and forwarding happens is up to a
protocol using packetbb - look for example at OLSRv2
and DYMO that have quite different forwarding behaviour.
The packetbb statement is true, but it doesn't mandate
that behaviour. These comments are based on a false
premiss.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 14 November 2007 07:50
To: 'manet'
Subject: [manet] Forwarding on packetbb <msg-header> only & MANET_ID TLV

               *** 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,

After private discussions and reading I-Ds over and over again, I still
do
understood, e.g. are defined for routing protocols that are not active
on

Let's use MANET_ID as example (draft-chakeres-manet-manetid-00.txt). I
think
it is unacceptable that information form region X leaks into region Y,
Z,
AA, .... ZZZZZ. Maybe it is not processed and not that harmful, but it
is a
waste of bandwidth. I can imagine much more evil examples, I used
MANET_ID
as I like this idea.

Cheers, Teco

********************************************************************
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: "Teco Boot" <[email-masked]>
Date: Wed, 14 Nov 2007 11:25:37 +0100

What about the opposite of quoted text?
<...start...>
   o  A message header format, which may not allow a node to make
      processing and forwarding decisions based on the node's present
      state and the message header, without inspecting and parsing the
      message body.  Message header information only does not permit single-
and
      multi-hop message diffusion.
<...>
   Separation of forwarding and processing  - duplicate detection and
      controlled scope message forwarding decisions cannot be made using
      information contained in the message header only, without processing
      the message body.
<...>
   Message  - the fundamental entity carrying protocol information, in
      the form of addresses and TLVs.  Messages are transmitted in
      packets, and may not be forwarded based on their header information.
<...>
   o  Messages are designed to be carriers of protocol information and
      MAY NOT, at each hop, be forwarded and/or processed according to the
      information in the message header only by the protocol using this
      specification.
<...end...>
May or may not, If we don't know what is meant, it is a bad standard.
If someone writes a new protocol, (s)he could check older protocols and try
to reduce evil side effects. This is not possible for the opposite.
I think this is a significant issue and I do not agree on current PacketBB
text.
Teco.

> -----Oorspronkelijk bericht-----
> Van: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Verzonden: woensdag 14 november 2007 10:34
> Aan: Teco Boot; manet
> Onderwerp: RE: [manet] Forwarding on packetbb <msg-header> only &
> MANET_ID TLV
> 
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Nov 2007 10:30:46 -0000

I really don't understand what Teco is trying to say
here. I am suggesting to my co-authors making it a
little more explicit (although it should be clear)
that processing and forwarding are done by a protocol,
packetbb provides the tools which those protocols
can use, with comments on how.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 14 November 2007 10:26
To: Dearlove, Christopher (UK); 'manet'
Subject: RE: [manet] Forwarding on packetbb <msg-header> only & MANET_ID
TLV

What about the opposite of quoted text?
<...start...>
   o  A message header format, which may not allow a node to make
      processing and forwarding decisions based on the node's present
      state and the message header, without inspecting and parsing the
      message body.  Message header information only does not permit
single-
and
      multi-hop message diffusion.
<...>
   Separation of forwarding and processing  - duplicate detection and
      controlled scope message forwarding decisions cannot be made using
      information contained in the message header only, without
processing
      the message body.
<...>
   Message  - the fundamental entity carrying protocol information, in
      the form of addresses and TLVs.  Messages are transmitted in
      packets, and may not be forwarded based on their header
information.
<...>
   o  Messages are designed to be carriers of protocol information and
      MAY NOT, at each hop, be forwarded and/or processed according to
the
      information in the message header only by the protocol using this
      specification.
<...end...>
May or may not, If we don't know what is meant, it is a bad standard.
If someone writes a new protocol, (s)he could check older protocols and
try
to reduce evil side effects. This is not possible for the opposite.
I think this is a significant issue and I do not agree on current
PacketBB
text.
Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 14 Nov 2007 12:23:52 +0100

We agree on that processing and forwarding is done by a protocol. However,
this is not specified.
We agree on that packetbb provides tools for forwarding decisions.

I think it is required to mandate that a protocol MAY NOT forward other
protocol information or forward information that MAY NOT be forwarded, e.g.
indicated by TLV within messages. That's why I suggest changing the text.
And I don't agree on that message header only inspection is enough.
<msg-type> and <msg-hop-limit> helps, but more inspection is needed and MUST
be mandated. And rules for <msg-hop-limit> are not defined in packetbb at
all. Nor a reference.

For a single protocol MANET, there is no problem. I think in real world,
problems will occur. Let's something, preventing those problems.

Teco.

> Verzonden: woensdag 14 november 2007 11:31
> Aan: Teco Boot; manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Nov 2007 12:31:04 -0000

> indicated by TLV within messages.

That's up to the protocols, it's outside the scope of packetbb.
What you say may make sense in some contexts, and may not in
others.

> And I don't agree on that message header only inspection is enough.

packetbb says that only header inspection may be enough.
(It's more specific in one place where it points out that
header inspection allows duplicate detection and scope
delimiting.)

> be mandated.

In a protocol, not in packetbb.

> And rules for <msg-hop-limit> are not defined in packetbb at
> all.

And rules should not be defined, only a suggestion (which we may
make slightly more specific) is in packetbb.

> problems will occur. Let's something, preventing those problems.

Mandating protocol rules, which may not be appropriate to all
protocols, in a document which is about formats, not a protocol
is creating, not preventing, problems.

Protocols (the ones we have, not abstract ones) need hop limit
and/or hop count. So packetbb supplies them. And supplying them
packetbb needs to say what they are. But we want the minimum of
specification of how to use them. As packetbb says in several
places, just in case anyone misses it in one, it's not a protocol.
Protocols specify forwarding rules. But some protocols may want
an efficient way to check if a message may be forwarded or
processed (or, in some cases, a first check) and that's how
packetbb is designed.

You're trying to turn packetbb into a protocol. It's not.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 14 Nov 2007 15:23:42 +0100

> is creating, not preventing, problems.
Agreed. Maybe we both have the same target. My comment is on claims written
in packetbb, which are dependent on the protocol and thus should not be
included in a document about formats. And the claims are invalid as soon as
new protocol extensions are introduced, e.g. MANET_ID.

> You're trying to turn packetbb into a protocol. It's not.
No, I am not. My comments are on the claims only. I prefer taking them out
or adjusting text that some packetbb fields are just helpful for protocols,
forwarding messages.
I am trying to turn packetbb into a format specification and getting rid of
text about forwarding as much as possible. Rules (or guidelines) on
<msg-hop-limit> are the exception. Here I want forwarding specification.

> and/or hop count.
On the abstract ones: I am facing day to day problems with protocols we
have. Mostly caused by inaccurate specification. Or short-term vision.
Adding MANET_ID in OLSRv2 is not that abstract.

I am reading the packetbb document with misbehaving protocols in mind. I
want to have text be corrected. A clear protocol specification or format
specification is very helpful in such circumstances.

Suggestions for corrections below. Please process this with ERP (Evil
Routing Protocol) in mind.

Teco.

====
 
Page 4:
, without inspecting and parsing the message body.  
>>> This is up to the protocol and not up to the format.
>>> can be removed.

Page 5:
>>> This is up to the protocol and not up to the format.
>>> can be removed.

Page 6
>>> May or may not. This is dependent on the protocol and the content of the
message. 
>>> Suggestion for better specification:
   Message  - the fundamental entity carrying protocol information, in
      the form of addresses and TLVs.  Messages are transmitted in
      packets, and may be forwarded based on their header information 
      and / or the content of the message.

Page 12:
   <msg-hop-limit>  is omitted if the mnohoplimit bit is set ('1'),
      otherwise is an 8 bit field, which contains the maximum number of
      logical hops that the message should be further transmitted.
>>> Suggestion for better specification:
   <msg-hop-limit>  is omitted if the mnohoplimit bit is set ('1'),
      otherwise is an 8 bit field, which contains the maximum number of
      logical hops that the message should be further transmitted.
      <msg-hop-limit> is decremented by 1 by each node that forwards the
      message. The message MUST NOT be forwarded if <msg-hop-limit> is 
      decremented to zero.

Page 25:
      specification
>>> Suggestion for better specification:
   o  Messages are designed to be carriers of protocol information and
      MAY, at each hop, be forwarded and/or processed according to the
      information in the message by the protocol using this specification

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Nov 2007 15:08:42 -0000

> text about forwarding as much as possible.

But no more. And

- Protocols need hop limit/count, and othe stuff is used for
  forwarding/processing decisions (such as duplicate detection).
- packetbb needs to supply those fields. And it makes some/many
  protocols more efficient to have that stuff in a header,
  while putting other stuff in the message body.
- packetbb needs to explain what those fields are and how
  they may be used, while not mandating that, because otherwise
  protocols don't know what's there for them.

And that's what we have. Give or take the odd minor wording
change, suggestions to strip out stuff wholesale are completely
at odds with what needs to be in packetbb. Every thing in packetbb
that is verging on protocol is something we, the authors, would
rather not have if it isn't necessary. But it is necessary, based
on the argument summarised above. Suggesting minor wording changes
may be useful. Suggesting stripping out every reference to forwarding
and processing isn't, they are there for a reason, and are
necessary for packetbb to do its job.

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 14 Nov 2007 10:26:50 -0500

I think its important to make clear to future protocol designers that
protocols can be designed in such a way where only message header
information is needed from the message.  I see where it seems we were
cutting the protocol out of the loop and I agree we should add it back in
but I also think that we should keep the message about what is possible as a
helpful hit to packetbb implementers/readers.

> >>> This is up to the protocol and not up to the format.
Processing is also misspelled there...

A message header format, which may allow a node to make
praocessing and forwarding decisions based on the node's present
state and the message header, without inspecting and parsing the
message body.

A message header format, which may allow a node to make
processing and forwarding decisions based on the node's present
protocol state and the message header, without inspecting and 
parsing the message body.  Protocols using this 
specification may require use of the entire message for these
decisions.

> >>> This is up to the protocol and not up to the format.
    Separation of forwarding and processing  - protocols using this 
	specification can be designed such that, duplicate detection and
      controlled scope message forwarding decisions can be made using
      information contained in the message header, without processing
      the message body.

> >>> May or may not. This is dependent on the protocol and the 
> content of 
> >>> the
> message. 

Yes I agree with minor change.

    Message  - the fundamental entity carrying protocol information, in
       the form of addresses and TLVs.  Messages are transmitted in
       packets, and may be forwarded based on protocol state and
       message header information.  Some protocols may require information
       from the entire message.
>       message. The message MUST NOT be forwarded if 
I disagree with this as protocols can use this field in a different way, for
example logical hops being more than one physical hop.  Because protocols
are doing all of the forwarding they really get to decide how this field is
used as long as it contains the maximum number of logical hops.  Leaving a
hint or note as to what we think will be the normal mode of operation may be
appropriate but enforcing that behavior I do not agree with.

>       information in the message by the protocol using this 
Disagree although I do see your point.  We are trying to convey that most of
the time protocols should have sufficient information with the message
header alone. By stressing this so much we left out pointing out that some
of the time it will not be possible.

     o  Messages are designed to be carriers of protocol information and
        MAY, at each hop, be forwarded and/or processed according to the
        information in the message header by the protocol using this 
        specification.  Some protocols may require information from the
        message body as well as the message header for forwarding and/or 
        processing decisions.

Justin

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 14 Nov 2007 17:21:23 +0100

> helpful hit to packetbb implementers/readers.
ACK

> specification may require use of the entire message for these
ACK
However, accepting something like MANET_ID will force all protocols to use
the entire message.

>       information contained in the message header, without processing
NACK.
I still think the claim is false.
Just using the word could, and I am fine. It is a bloody minor detail, but I
had nightmares for less.
--> forwarding decisions could be made

>      message header information.  Some protocols may require information
ACK

> appropriate but enforcing that behavior I do not agree with.
Personally I don't like these logical hops at all. I requested to remove
this in my review mail.
Can we agree in decrement (without "by 1") and discard when zero?
Maybe change MUST NOT into SHOULD NOT (although I see not why)?

      <msg-hop-limit> is decremented by each node that forwards the

If not, please provide a reference to a protocol that needs something else.
I am very interested, also because my nightmares!

>       message body as well as the message header for forwarding and/or
ACK

I hope we can close this one and go forward with more important issues.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Nov 2007 16:26:22 -0000

The next version of packetbb will have some revised text in these
areas (and some others). At the moment the current draft still
needs one of the authors to sign off on it, so I don't have it to
present here. I suggest waiting for that version (which will be out
as soon as possible, I hope submitted today, but can't promise).

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 14 November 2007 16:21
To: 'Justin Dean'; Dearlove, Christopher (UK); 'manet'
Subject: RE: [manet] Forwarding on packetbb <msg-header> only & MANET_ID
TLV

               *** WARNING ***

> but I also think that we should keep the message about what is
possible
> as a
ACK

> specification may require use of the entire message for these
ACK
However, accepting something like MANET_ID will force all protocols to
use
the entire message.

NACK.
I still think the claim is false.
Just using the word could, and I am fine. It is a bloody minor detail,
but I
had nightmares for less.
--> forwarding decisions could be made

ACK

If not, please provide a reference to a protocol that needs something
else.
I am very interested, also because my nightmares!

ACK

Teco