Subject: [manet] NHDP + MANET_ID TLV

From: "Ian Chakeres" <[email-masked]>
Date: Sat, 2 Feb 2008 17:27:53 +0530

I would like to see NHDP use the MANET_ID TLV
(http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-03.txt).

I think that NHDP, and our other protocols, should allow network
operators to run multiple instances independently on the same node
over
the same interfaces. I believe that the MANET_ID I-D presents an easy
and well understood way to do this.

If you have an opinion on this matter, please respond to this email.

Ian Chakeres

Note: I do not think that inclusion of the protocol operations from
MANET_ID will be at all challenging to add to NHDP or our other
protocols.
_______________________________________________
manet mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/manet

---

From: "Ian Chakeres" <[email-masked]>
Date: Sun, 3 Feb 2008 12:36:12 +0530

Jerome, thank you very much for the comments on manetid-03. I will
integrate the comments in the next revision.

Regarding, delaying WG deliverables. I believe that given that this
feature is already well-understood and specified, it would result in
no measurable delay of WG documents moving forward.

Note: that after WGLC all standard documents must still undergo IETF
LC, as well as IESG review.

Ian Chakeres

On Feb 3, 2008 5:29 AM,  <[email-masked]> wrote:
> Dear Ian and WG members,
>
> My humble opinion would be to agree on this idea. Eventhough we do not
> have a problem statement yet, and that Manet_ID is not at this time a
> WG document, allowing different providers (or the same provider
> actually) to run different instances of a same protocol would require
> such differenciation.
>
> My concern is that we do not have a problem statement, and it might
> take time to write it and present it (let's say until the next IETF).
> That might therefore freeze the ungoing process of NHPD, DYMO, SMF and
> OLSRv2. Basically, writing a problem statement and discussing during
> the next IETF signifies that NHDP would not be able to be sent to the
> secretariat before it. Would the WG agree that this would be worth it
> ? Is there any other solution for a self sustained MANET_ID document ?
>
> On MANET_ID itslef, you may not limit your draft to DYMO and NHDP. I
> would also see eventually OLSR and SMF to be able to be have multiple
> instances independantly run on a same interface.
>
> Some comments on the draft itself:
>
> Introduction: bad link for the 'ID ietf-manet-dymo' and 'packetbb'
>
> in order not to restrict the scope, I would write not mention DYMO
> itslef, but a MANET protocol.
>
> 'information' should be defined (is it its configuration, its state, etc...)
>
> Section 3: bad link with packetBB
>
> Section 4 (and remark on NHDP): Adding the required changes to NHDP in
> different places in the NHDP spec (probably in HELLO Message
> Generation, HELLO Message Processing, and Protocol Parameters and
> Constants) might trigger more comments, that could not be processed
> before tomorrow. So, do you plan to extend the WGLC to complete the
> discussion on the opportunities to use MANET_ID ?
>
>
> Regards,
>
> Jerome
>
> Ian Chakeres <[email-masked]> a écrit :
>
>

---

From: [email-masked]
Date: Sun, 3 Feb 2008 00:59:41 +0100

Dear Ian and WG members,

Regards,

Jerome

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 4 Feb 2008 16:14:53 +0100

Dear Ian, MANET wg.,

I am strongly leaning against including MANET_ID in NHDP (and DYMO  
and OLSRv2 and SMF, for that matter).

The reason is that while I understand (part of) what this I-D is  
trying to do, I do not feel that the problem is fully analysed,  
understood and described by the working group (in particular, I am  
not convinced that the problem-space is sufficiently explored to be  
able to device a mechanism deemed appropriate). I am saying this  
since there are other ways of doing multiple independent protocol  
instances on the same router and where it is possible to discriminate  
the control-traffic/topology using (e.g.) components of IP addresses  
or prefixes -- and this without adding additional mechanisms such as  
those described in the MANET_ID I-D. I know, because I've done it ;)

I am, therefore, not convinced that for this simple objective an  
additional mechanism is needed or useful, other than as a mechanism  
to determine the boundaries of a given MANET. Such boundaries can, as  
stated and at least in some scenarios, be done without additional  
mechanisms being introduced but through using address/prefix  
components. In other scenarios I can imagine this (defining  
boundaries using address components) being combined with existing  
IETF protocols (NEMO and other such "IP session continuity"  
mechanisms come to mind) for mobility across boundaries.

So, for the scenario that I can think of, we do not need an  
additional mechanism to be introduced.

For other possible scenarios, I am even not convinced that the need  
to discriminate control traffic between multiple instances is clearly  
understood as useful on MANET interfaces/routers:

If the goal has to do with allowing multiple-topologies for catering  
to different (classes of) application requirement, then I believe  
that the interaction between such instances and any shared networking  
resources (e.g. with respect to access to the medium and/or resource  
reservation) needs to be managed -- which approaches QoS and which is  
not addressed by this I-D.

If networking resources are not shared (e.g. the different instances  
are not sharing the same network interface(s) and/or communications  
medium), then no such mechanism is required -- however any  
interaction between such two instances might require something-BGP- 
like (I believe that Sue brought up at the last IETF that this was a  
domain where there is a lot of previous experiences to explore?)

I would therefore like to strongly suggest that prior to continuing  
discussions on the solution described in MANET_ID, the wg tries to  
analyse the problem, understand scenarios and their requirements  
before devising a solution.

Note that I am not saying that MANET_ID is a good or bad solution. I  
am saying that I don't know since the wg has not determined if there  
is a problem, described what it is and analysed the requirements to a  
solution.

I believe that others have pronounced themselves similarly on the  
MANET M-L.

Sincerely,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 4 Feb 2008 16:23:10 +0100

Jerome,

> actually) to run different instances of a same protocol would require

Ok, adding to the complications here, when you are talking about  
potentially multiple providers: I do not think that a simple ID tag  
would suffice, but that something involving a "secure token" would be  
required -- least we would open the door to potentially another  
attack vector. This, btw., applies also to a single-operator with  
e.g. different fees for different "classes of service" (in case one  
would consider multi-topology for this purpose).

> take time to write it and present it (let's say until the next IETF).

That'd be even very optimistic.

> ? Is there any other solution for a self sustained MANET_ID document ?

On my behalf, I do not feel that delaying NHDP/SMF/DYMO/OLSRv2  
pending the analysis of if there is a problem and, if so, how it can  
best be solved, would be acceptable. As stated elsewhere, I feel that  
the problem is sufficiently vague that we would need a good chunk of  
time reaching a common understanding as to what it and is not  
included (as per my previous email and the "secure token" comment  
above), and then subsequently time to device the solution.

I am glad that you brought up the multiple-operator thought, though,  
since it brings forward another set of considerations.

Thomas

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 6 Feb 2008 12:05:29 +0530

I believe that using an ID to hinder processing of protocol
packets/messages is a well-known technique to operating multiple
instances of a protocol on the same node over the same interfaces.

You mentioned using additional IP addresses information about which
addresses belong to which instance to enable this type of operation as
a possible solution. This proposed solution allows multiple instances,
but those instances must have disjoint address spaces. Although this
might work in certain limited scenarios, I do not think this is a
manageable solution and I would not recommend it.

If there are other well-known methods to enable multiple instances for
our protocols in a simple fashion, please bring them up now. I would
be happy to consider other methods.

Other comments inline.

> not addressed by this I-D.

Although using multiple topologies is a features of using an ID to
distinguish instances, and multiple topologies could be used for
different QoS classes - This is not the focus of the proposed method,
behavior, or document. I would say the same holds for other routing
protocols using a similar mechanism to enable multiple instances.

> before devising a solution.

In your opinion, how should this be accomplished?

What is your main concern and why do you not like the ID based method?

I would like guidance on how I might convince you that MANET_ID is the
right approach.

> I believe that others have pronounced themselves similarly on the

I believe there has been active support for allowing multiple instances.

For those expressing disagreement, I think the comments have mainly
revolved around not understanding the problem.

Ian Chakeres

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 Feb 2008 09:38:44 -0000

> be happy to consider other methods.

This has the cart and the horse round the wrong way. First should
be a specification of what exactly you are trying to achieve, and why.
That is, a problem statement. It needs more than just "multiple
instances" but how you want to run multiple instances, and why.

********************************************************************
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: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Feb 2008 14:36:23 -0800

IMHO, what the manetid doc needs is an _applicability_
statement, which is perhaps a step closer to solution
space than a problem statement. For example:

  - does the solution apply only to relatively static
    MANETs with managed configuration of instance IDs?
  - can the IDs be assigned via AUTOCONF mechanisms?
  - does the ID name only the routing protocol instance,
    or does it also name the entire MANET (as the new
    name "MANET_ID" implies)?
  - what is the expected behavior in dynamic MANETs
    that partition and merge?

I think clarifying the domain of applicability, as
well as identifying any areas of overlap such as with
AUTOCONF work, would be a big help but may require
vetting in multiple working groups. I have no opinion
wrt inclusion in the NHDP or any of the routing protocols
at this time.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: Thomas Clausen [mailto:[email-masked]] 
> Sent: Monday, February 04, 2008 7:15 AM
> To: Ian Chakeres
> Cc: manet
> Subject: Re: [manet] NHDP + MANET_ID TLV
> 
> Dear Ian, MANET wg.,
>