Subject: [Manet-dt] pre-edit version 1 of SMF ID for design team input

From: "Joe Macker" <[email-masked]>
Date: Tue, 4 Oct 2005 18:41:28 -0400

All:

Hey SMF DT, I have been out sick for a few weeks, but I've been able to put
some time into SMF.  Brian and I have been to put new revision of SMF
together. I've named it 01-pre for now.

We added a few things based on Charlie's input from bcast, revised some text
based upon input from Brian Haberman and Maoyu Wang, and added some other
content and revision including a rough options header outline and some other
TBDs.

We'd like to get more design team input and review prior to submission and
talk more about issues like the potential for a common neighbor discovery
approach.  Obviously, with an EXP target there can be some more TBDs here
than in other specs, but we'd like to have good convergence with other WG
docs as well.  The common message format discussion may help here.

Brian and I will be out tomorrow but would like to get input over the next
week.

Thanks,
-Joe
_______________________________________________
Manet-dt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet-dt

---

From: Brian Adamson <[email-masked]>
Date: Wed, 5 Oct 2005 10:49:29 -0400

One note I would add here is that this new SMF draft could make good 
use of e a baseline "Neighborhood Discovery Protocol"  that could be 
leveraged in the absence of a concurrent MANET routing protocol 
providing local neighborhood topology information.  I use the term 
"neighborhood" since 2-hop knowledge is needed for some of the relay 
set algorithms (or perhaps "n-hop" would be useful for some purposes?)

With the recent discussion on perhaps having a "common generic MANET 
message format", I would propose that it might be possible to create 
a "MANET Neighborhood Discovery Protocol" document that _also_ 
defines the framework for common message format ...

SMF could reference/leverage this document when needed, _and_, at 
their discretion, MANET routing protocols (e.g., DYMO or OLSRv2) 
could use the message format framework and/or neighborhood discovery 
protocol as appropriate.

The current SMF draft has Appendices to describe a few relay set 
algorithms for SMF purposes.  It is possible that other relay set 
selection algorithms could be described in separate documents in the 
future using the SMF Appendice format as a sort of "template"

With regards to  relationship to  a common message 
format/Neighborhood Discovery document, the SMF Appendices have TBDs 
to specify any necessary type/length/value fields (TLV) to be carried 
in Neighborhood Discovery messages (assuming the common message 
format) ... The idea is that different relay set algorithm specs 
could extend the neighbor discovery messaging as needed  ...

This stuff is hinted at in the current SMF draft, but I wanted to 
point this out to the design team for their consideration.

At 6:41 PM -0400 10/4/05, Joe Macker wrote:
>Attachment converted: macsheen:draft-macker-manet-s#171A0A.txt 
>(TEXT/ttxt) (00171A0A)

-- 
Brian

Brian Adamson
<[email-masked]>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Oct 2005 18:54:17 +0300

Hello Joe,

I hope you are feeling better.  I have some comments on
the document.  Do you think that some of the missing sections
will be filled in before publication?  The text that is there is
good, but the gaps tend to diminish the overall credibility of
the document, it seems to me.  Maybe this is illusory.

>docs as well.  The common message format discussion may help here.

Editorial: that word "leverage" usually only belongs on PowerPoints.
Perhaps instead "make use of".

- If the neighborhood discovery algorithm is not going to be
  part of this document, then at least we should suggest some
  constraints it has to fulfill.  Here is a straw paragraph for your
  consideration.

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

"The minimum information that a node requires from any
  neighborhood discovery algorithm is a list of the IP addresses
  and MAC addresses of its neighbors, but more information is
  possible.  Two additional categories of information have been
  shown to have value for selecting relay sets:
  = Connectivitiy information about the neighbors (i.e, which
     neighbors have link to other neigthbors
  = Two-hop neighborhood

  If, as expected, different algorithms are explored during the
  evolution of the relay set selection specification, these
  algorithms should be robust enough to still work when
  provided with incomplete information.  So, for example, an
  algorithm that is developed to minimize the size of the
  selected set of relays using two-hop neighborhood information
  must still work correctly, if not optimally, under situations
  where some of the nodes in the ad hoc network only provide
  the minimal one-hop neighborhood information".

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

Editorial, section 3: insert "different" before
     "sequence number per <..."

Citation required for "Essential CDS"

I don't think we should consider making any specification
for the IPv4 SMF-DPD header option, so that placeholder
section should be deleted.

The timeout for stored information about flooded packets
needs to be a lot longer than "Net_Traversal_Time", to
take into account anomalous conditions and longer-than-average
paths for packet dissemination.  I'm not sure how long,
but maybe even 10 times as long is reasonable.  Perhaps
someone has some simulation results that would apply.

I think that the hop-by-hop option formulation for the IPv6
packet is fine, and that making it a destination option does
not add any value.  At least I don't see the value right now.

At some point, it might be a good idea to discuss what
changes are needed to store "sparse" multicast groups.
Or, if SMF was already intended to handle that also,
it wasn't clear to me from my initial reading.

Regards,
Charlie P.

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 13 Oct 2005 14:33:04 -0400

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Thursday, October 13, 2005 11:54 AM
>To: Joe Macker
>Cc: [email-masked]
>Subject: Re: [Manet-dt] pre-edit version 1 of SMF ID for 
>design team input
>
>
>Hello Joe,
>
>I hope you are feeling better.  I have some comments on the 
>document.  Do you think that some of the missing sections will 
>be filled in before publication?  The text that is there is 

It think are naturally some TBDs we need to evolve.
I am less worried about them being in SMF then the other protocols.
Which missing sections are you most worried about?

The gateway one would be my first choice.
As outlined neighbor discovery and group-specific can wait in my opinion.
I like your idea of outlining constraints that we understand for now.

>
>>We'd like to get more design team input and review prior to 
>submission 
>>and talk more about issues like the potential for a common neighbor 
>>discovery approach.  Obviously, with an EXP target there can be some 
>>more TBDs here than in other specs, but we'd like to have good 
>>convergence with other WG docs as well.  The common message 
>format discussion may help here.
>>  
>>
>
no problem.
>  constraints it has to fulfill.  Here is a straw paragraph for your

Good idea...as you know there are different constraints for CDS algorithms
discussed.
There might be value in pointing out the dependencies. I think we had
something like that in an earlier version.  We will revise to work this in..

Or were you thinking just point out the least common denominator of
constraints?
I am little concerned about requiring the MAC addresses.

>I don't think we should consider making any specification for 
>the IPv4 SMF-DPD header option, so that placeholder section 
>should be deleted.

Ok, that was thrown out there to stimulate DT reponse.

>
>The timeout for stored information about flooded packets needs 
>to be a lot longer than "Net_Traversal_Time", to take into 
>account anomalous conditions and longer-than-average paths for 
>packet dissemination.  I'm not sure how long, but maybe even 
>10 times as long is reasonable.  Perhaps someone has some 
>simulation results that would apply.
>

O.k., You had previously mentioned that to me.

>
>At some point, it might be a good idea to discuss what changes 
>are needed to store "sparse" multicast groups.
>Or, if SMF was already intended to handle that also, it wasn't 
>clear to me from my initial reading.

Brian and I have been thinking forward about how to do that with the
implementation state maintenance, but you are correct it is not discussed
yet.