Subject: [manet] I-D Action:draft-chakeres-manet-manetid-01.txt

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 14 Jan 2008 16:55:49 +0530

I've gotten around to revising the MANET_ID Internet-Draft. I have
modified it to be very specific to DYMO, but I think it would be easy
to generalize to other MANET protocols.

The meat of the Internet-Draft is less than a page of text, please
review it and send me comments/feedback.

I would like to have a discussion on-list about whether you think this
type of functionality is important and whether we should include
something similar in other standards track MANET documents.

I think it is important.

Ian Chakeres

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2008/1/14
Subject: I-D Action:draft-chakeres-manet-manetid-01.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : MANET_ID TLV
        Author(s)       : I. Chakeres
        Filename        : draft-chakeres-manet-manetid-01.txt
        Pages           : 6
        Date            : 2008-01-14

This document defines a packet and a message TLV named MANET_ID.  The
MANET_ID TLV is used by DYMO routers to identify information that
should be processed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
        "get draft-chakeres-manet-manetid-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-chakeres-manet-manetid-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 15 Jan 2008 09:09:10 +0100

Hi Ian,

Thanks for updating the draft.
I support the idea. Here some comments:

- I think the MANET_ID is most applicable to messages.
  You removed the address TLV. I agree on this.

- I think there is no fundamental difference in adding MANET_ID 
  to DYMO, OLSR, NHDP or whatever MANET routing protocol using packetbb.
  I prefer the generic specification as it was in version -00.

- Intended status:
  I agree on the intended status, being Standards Track.

- There is small impact on packetbb, I raised this before.
  The text in packetbb paragraph "Separation of forwarding and 
  processing" is not valid anymore, as information contained in the 
  message body MUST be analyzed before forwarding. Maybe some would 
  say analyzing is not processing....

- Abstract:
  >> The MANET_ID TLV is used by DYMO routers to identify information
  >> that should be processed.
  I would use the word shall instead of should. Or just rewording, e.g.:
  << The MANET_ID TLV is used by MANET routers to identify information 
  << for further processing.

- 1.  Introduction
  Again should <--> shall

- 3.  MANET_ID TLV Structure
  >> If the MANET_ID TLV is attached a packet or message, then it 
  >> must be a single value TLV as defined in [I-D.ietf-manet-packetbb].
  This is true in all cases, suggested text:
  << The MANET_ID TLV is a single value TLV as defined in 
  << [I-D.ietf-manet-packetbb].

  And bytes <--> octets

- 4.  DYMO Protocol Operation
  As mentioned above, I prefer changing DYMO into MANET.
  And I prefer using the word _specifies_ instead of _recommends_.
  Suggested text:
  << 4.  MANET Routing Protocol Operation
  <<
  << This document specifies MANET routing protocol instance behavior
  << based on the MANET_ID TLV value.

- 4.1.  DYMO Router Configuration
  Only DYMO <--> MANET

- 4.2.  Packet Processing
  >> When a packet is received containing a MANET_ID TLV, the 
  >> MANET_ID value is attributed to all messages contained 
  >> within the packet.
  This implies that such a packet, also containing MANET_ID TLV tagged
  messages is invalid. I suggest adding the following text to
  this paragraph:
  << A MANET_ID tagged packet containing MANET_ID tagged messages 
  << are invalid and MUST be discarded and ignored.
  Maybe someone has another opinion on this. 
  See also proposal below on new text for supporting multiple instances.

 - 4.4.  Sending Packets/Messages
  Again DYMO <--> MANET

  In case the MANET router's MY_MANET_ID value is not zero (0),
  the information MUST be tagged.
  In case the MANET router's MY_MANET_ID value is zero (0),
  the information SHOULD NOT be tagged.
  You could modify the text and specify both case, e.g.:
  << 
  << When issuing MANET routing protocol packets/messages and the 
  << MANET router's MY_MANET_ID value is not zero (0), the
  << information MUST be identified by tagging it with a MANET_ID
  << TLV containing this MANET router's MY_MANET_ID value.
  << 
  << When issuing MANET routing protocol packets/messages and the 
  << MANET router's MY_MANET_ID value is zero (0), the information
  << SHOULD NOT be identified by tagging it with a MANET_ID TLV.
  << 

- New
  I would like adding a subsection (4.5) on a MANET router that 
  processes packets/messages of multiple MANET_IDs. I do not suggest
  using terms like border router or manet regions, but of course 
  MANET_ID enables this kind of mechanism.
  Suggested text:
  <<
  << 4.5.  Processing Multiple MANET_IDs  
  <<
  << A MANET Router MAY process packets/messages with different 
  << MANET_IDs. In such a case, the MANET Router has a set of 
  << MY_MANET_ID values. Each MY_MANET_ID is related with a MANET
  << protocol instance.
  <<
  << On packet/message reception, all information tagged
  << with a MANET_ID value that is not in the set of MY_MANET_ID 
  << values is discarded and ignored.
  <<
  << On packet/message processing, the MANET Router MUST process
  << information for the MANET_ID instances separately and all information
  << in the MANET_ID instances MUST be isolated, unless a MANET protocol
  << specification explicitly mentions otherwise.
  <<
  << On sending packets/messages, the MANET Router MUST tag information
  << with the MANET_ID instance for non-zero MANET_ID values. Again, 
  << information with MANET_ID value zero (0) SHOULD NOT be tagged. A 
  << packet with messages with only a single MANET_ID value SHOULD be 
  << tagged with a packet MANET_ID TLV. Packets tagged with a MANET_ID TLV 
  << MUST NOT contain messages tagged with MANET_ID TLV.
  <<

- New
  I prefer adding text on MANET Router behavior that does not 
  support MANET_ID functionality, e.g.:
  <<
  << 4.5.  MANET_ID support as optional feature
  <<
  << A MANET Router that does not support MANET_ID functionality MUST
  << discard and ignore all packets or messages that contain a MANET_ID
  << TLV with a nonzero value and MUST send packets/messages without
  << a MANET_ID TLV. Such a MANET Router is compatible with a MANET_ID 
  << capable MANET Router running a MANET protocol instance with a 
  << MANET_ID value zero (0).
  <<

- 5.  IANA Considerations
  I think the MANET_ID TLV types should be within the range 0-7 as they 
  should (or MUST) appear in front of other TLVs in the TLV block.

  Requesting TLV types also implies requesting TLV type extensions (see
  timetlv-04 for example text).

- 8.  References
  Add references to the MANET Protocol documents (DYMO, OLSR and NHDP)?
  Timetlv is at version -04.

Regards, 
Teco.

> -----Oorspronkelijk bericht-----
> Van: Ian Chakeres [mailto:[email-masked]]
> Verzonden: maandag 14 januari 2008 12:26
> Aan: manet
> Onderwerp: [manet] I-D Action:draft-chakeres-manet-manetid-01.txt
>

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 16 Jan 2008 17:21:48 +0530

Teco, thank you very much for your comments.

More inline for everyone.

On Jan 15, 2008 1:39 PM, Teco Boot <[email-masked]> wrote:

<snip>

>   I prefer the generic specification as it was in version -00.

I tend to agree, but I want to hear from everyone whether they think
this type of behavior needs to be applied to NHDP & OLSRv2.

Everyone - please chime in with you thoughts.

Until more consensus exists , I will keep the text specific to DYMO.

<snip>

>   See also proposal below on new text for supporting multiple instances.

When information is tagged with multiple the_manet_id(s) things do get
tricky. I see several options here. I agree "invalid" is probably the
easiest.

We should probably startup a new conversation on this item, if we
choose to proceed.

>   << 4.5.  Processing Multiple MANET_IDs

<snip>

I have changed the text everywhere to reflect that my_manet_id is
local to a (DYMO) routing protocol instance. This revision clears up
some of the questions regarding running multiple routing processes.

Note that, it still leaves the above question about information tagged
with multiple the_manet_id(s) open. And the question about a single
routing process instance processing information form multiple
the_manet_id(s).

>   << MANET_ID value zero (0).

I agree this functionality (MANET_ID) should be "understood" by all
the (DYMO) routers. Otherwise, it nearly nullifies the intent and
benefit.

My intention is to put the behavior into the base DYMO spec.

Thanks again,
Ian

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Wed, 16 Jan 2008 09:27:30 -0800

Is this an imaginary problem (so far) that we are trying to solve or
there are examples that we can cite where having this functionality
has been crucial to running a network? Experience from OLSR folks is
highly relevant because they have deployed the network in public
settings so perhaps are aware of situations when this functionality is
desirable or crucial.

- om_p

---

From: "Ian Chakeres" <[email-masked]>
Date: Thu, 17 Jan 2008 10:18:36 +0530

The best example use is multi-topology routing (MTR) in OSPF. MTR is
being used often, especially in heterogeneous wireless networks. From
a solution perspective, OSPF has area and instance identifiers.

In my opinion this internet draft fixes is a well-known problem with a
well-known solution.

I believe this functionality is desirable and crucial.

Ian

---

From: "Omprakash Gnawali" <[email-masked]>
Date: Wed, 16 Jan 2008 21:15:46 -0800

> being used often, especially in heterogeneous wireless networks. From

Which wireless network?

- om_p

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Jan 2008 09:35:44 -0000

However the functionality (separation of separate domains)
can also be achieved using addresses, and I know people
have also done that. As indicated at the last IETF, I think
this is a solution before we have a problem statement.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 17 January 2008 04:49
To: Omprakash Gnawali
Cc: manet
Subject: Re: [manet] I-D Action:draft-chakeres-manet-manetid-01.txt

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

Ian

********************************************************************
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: "Ian Chakeres" <[email-masked]>
Date: Thu, 17 Jan 2008 15:25:45 +0530

I don't think separation of addresses is a good solution for MTR.

Ian Chakeres

---

From: "Joseph Kopena" <[email-masked]>
Date: Tue, 22 Jan 2008 16:25:00 -0500

> to generalize to other MANET protocols.

Hi Ian & everyone,

Some comments on version 2 of this draft.

Most importantly, if the draft is to be so tightly constrained to
DYMO, what is the value of having it as a second draft as opposed to
direct incorporation into DYMO?  I see three cases for having this
distinct draft:

  (1) It's necessary for IANA action or makes the standardization
      process easier (I do not fully understand the process of having
      numbers assigned and maintained).

  (2) This part of DYMO could and likely will be extended, replaced,
      or augment w/ alternates at some time, preferably without
      requiring major surgery on the primary DYMO spec.

  (3) It's generic enough to be reused by other protocols and systems.

If (1) is the motivation, then this draft seems entirely reasonable.
Case (2) does not seem to be obviously applicable to this draft.  I
don't see the stated functionality to be a likely candidate for easy
extension or replacement (unlike, for example, metrics).

Case (3) does seem to apply though, excluding the specific
restrictions to DYMO.  It seems like this functionality could
certainly be used in other protocols but is not so broad as to warrant
huge argument over its meaning and uses.  Earlier I had argued it
should not be restricted to message TLVs, but I am ok with such
restrictions if they gain clear, well delineated meaning usable by
other protocols.

In practical terms, am I correct in reading this draft as essentially
applying to the case that several protocol instances, possibly of
different types, are operating over the same medium, network, and
sockets?  For this to really apply and not be redundant, the instances
need to be listening to the same traffic, correct?

In that sense, the ID is a demultiplexer.  Should we therefore tone
down the language such that it's less about rejecting traffic, and
more about demultiplexing?  An architecture I see as desirable is
being able to run one NHDP process and hook multiple protocol
instances into that process such that messages may be aggregated into
packets, e.g. NHDP's HELLOs, and share comms overheads.  In that case,
it may be useful for the NHDP process to use the MANET ID to
demultiplex the messages back up to the processes.  In this case it's
not rejecting the messages, it's processing them based on the ID.
That can't necessarily be done by the message types alone (i.e. two of
the same instances), and certainly not be TLVs of those protocols, so
it would be useful but does not gel with the draft as written.

Similarly, I like that the discussion on packets and multiple messages
in the previous version was removed.  The ID and potential
invalidation (or processing) should be constrained to particular
messages, such that different IDs may be used by different messages
within a packet.

On a related note, is it necessary to restrict the ID to a single
octet?  It might be useful to permit arbitrary length IDs, helping
ensure unique identifiers without a priori management specifically to
orchestrate these IDs.  For example, if I use a domain name as my ID
it's unlikely it will conflict with anyone else's.  Disadvantages are,
as usual, extra bandwidth and processing cost.  With the draft as
written, you don't need to do anything with those IDs except recognize
yours, i.e. there's no state being indexed or maintained based on
them, so this should not be overly costly even on constrained
platforms.  This is more of an issue for the demultiplexing
functionality discussed above, and mechanisms like that.

Last point for now: Would it be worthwhile in the security
considerations to note that in no way should this mechanism be assumed
to provide authentication, certification, etc?  I.e., explicitly,
simply mention that using the MANET ID in control traffic does not
prevent any attacks such as contamination w/ bad control traffic, and
should not be used in such a fashion?

Thx!

-- 
- joe kopena
  right here and now

---

From: "Ian Chakeres" <[email-masked]>
Date: Thu, 24 Jan 2008 14:29:04 +0530

Thanks for your response Joe.

Comments inline.

>       numbers assigned and maintained).

I personally do not think that IANA should be involved with choosing a
MANET_ID, although that is an interesting concept.

>       requiring major surgery on the primary DYMO spec.

The protocol operation portion of this document would/will be shifted
into the protocol specs. The current location (in-document) is simply
to assist in the discussion.

>   (3) It's generic enough to be reused by other protocols and systems.

This option is the motivation behind this draft.

> need to be listening to the same traffic, correct?

Yes, this solution will be useful for cases where multiple instances
are "sharing" some operating resource.

> it would be useful but does not gel with the draft as written.

Let me give another example, you are running multiple OLSRv2 instances
each in a separate topology. Each topology one uses a different
metric. Demultiplexing is an issue, but it is important that a OLSRv2
router not participating in a particular topology not forward other
OLSRv2 messages.

> functionality discussed above, and mechanisms like that.

Moving forward, I plan to change the length to be variable.

> should not be used in such a fashion?

I would like to flush out the security section.

I agree that the MANET ID by itself does not provide auth/cert, but I
do not want to say that it could not be used (perhaps with other TLVs)
to help perform auth/cert.

Thanks for the feedback, I'll use it to update the document soon.

Ian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Jan 2008 11:56:22 -0800

Ian, 
 
> Moving forward, I plan to change the length to be variable.

Variable length is certainly better and goes toward addressing
one of my concerns. However, I agree with Chris that this seems
to be moving forward w/o a problem statement.

Fred
[email-masked]