Subject: [manet] Draft Agenda for MANET WG at IETF 69

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 11 Jul 2007 08:00:35 +0530

The MANET meeting is scheduled for Wed March 25th at 9am.

I've posted a draft agenda at
http://www3.ietf.org/proceedings/07jul/agenda/manet.txt. If you have
any other topics you'd like added, please email Joe & I ASAP.

I'd also like to use this opportunity to ask you to give a thorough
review to http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-01.txt
and http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-07.txt.
Both these documents are in working group last call.

Please also review the other current WG documents. A complete list
with links can be found on our charter page at
http://www.ietf.org/html.charters/manet-charter.html.

I look forward to seeing you in Chicago.
Ian Chakeres

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Jul 2007 17:22:48 -0700

This document is important and needs to go forward soon, but
overall comment is that the IPv4 DPD appears tenuous. Specific
comments follow:

Fred
[email-masked]

1) (editorial) Abstract, s/educed/reduced/

2) (semi-substantial) Section 4, the term "local host" is
used incorrectly in several places. In particular, hosts do
not forward packets; routers do. Suggest changing "local host"
to one of router/MANET router/SMF router.

3) (substantial) Section 5.1, first paragraph, this text
is advocating having network elements rewrite the ip_id field.
The ip_id field is specified as to be set in a manner chosen
by the source and used by the destination; it is therefore an
end-to-end consideration and not something intended for
modification by network middleboxes. Even if this were not so,
however, the disadvantages listed in the final paragraph of
Section 5.1 would seem to offset any perceived benefits in ip_id
rewriting, and may preclude a truly general-purpose solution
since it may not work well in all environments.

4) (semi-substantial) Sec 5.1, third paragraph, an arbitrary
multicast source cannot necessarily determine that it is an
"SMF intended source" and as such cannot be counted on to set
the DF bit. Suggest dropping this paragraph, as there should
be no perceived difference between multicast data plane
forwarding in an SMF forwarding region than in any other
multicast forwarding region.

5) (semi-editorial) Section 5.2.2, the "Tagger ID" field is
variable-length, but Fig. 3 does not show it as such.

6) (semi-editorial) Section 5.2.2, the variable name: "DPD
packet identifier" in the text does not match the field
name "DPD Sequence Value" in Fig. 3.

7) (semi-editorial) Section 5.2.2, the table of Tagger ID
type values, for value 3 change: "IPv4 address" to:
"IPv6 address". Also, the table should have a caption.

8) (semi-substantial) Section 5.2.2, the IDLen field length of
only 4bits restricts the potential length of the Tagger ID
field to at most 16 octets. But, future uses may require a
longer field for a different sort of ID such as the tagger's
public key, a DNS FQDN, etc. Possible solution is to reserve
one ID type (e.g., 7) as an indication that an "extended"
IDType/IDLen field follows (reserved for future use is fine).

9) (editorial) Section 5.2.4, s/[RFC1321]hash/[RFC1321] hash/

10) (editorial) Section 5.2.4, s/is only be/is only being/,
and immediately afterward s/reasonable/reasonably/.

11) (editorial) A number of additional editorial items
similar to 9) and 10) appear throughout the rest of the
document; these will presumably be corrected by RFC editor.

12) (substantial) Section 8.3, suggest dropping re-sequencing
of ip_id, i.e., same comment as 3).

13) (suggestion) Instead of having an SMF forwarding node
re-sequence an IPv4 multicast packet's ip_id, have it
encapsulate the packet in an outer IPv4 hdr with source
address set to its own IPv4 address, destination address
set to a site-scoped "All_SMF_Routers" and ip_id set in a
sequencing fashion (e.g., monotonically-increasing). The
outer source address is then a "Tagger ID", and the outer
ip_id can be used along with the inner (source, destination,
ip_id)-tuple as a DPD tag.

---

From: "Teco_Boot" <[email-masked]>
Date: Thu, 12 Jul 2007 09:11:24 +0200

Comments inline.

> since it may not work well in all environments.

[Teco] 
Absolutely right. And the proposal breaks RFC791. I know many IP stacks use
ip_id different, but IETF documents defining new roles for ip_id shall at
least note the difference with RFC791. And argument why the update is
needed.

Remember also the idea using DPD as filter for looped unicast packets, when
a loop occurs during convergence (draft-boot-manet-nemo-analysis-01.txt,
section 6.3).

---

From: Bruce M Simpson <[email-masked]>
Date: Thu, 12 Jul 2007 14:37:06 +0100

> ip_id)-tuple as a DPD tag.

The current state of the SMF memo is such that it says nothing about 
interoperability with existing PIM routing domains.

I like this suggestion as it potentially makes the integration of MANET 
SMF with existing IP multicast forwarding code in BSD-derived code easier.

MANET multicast traffic using the SMF scheme needs to be flooded along 
the MPR mesh; therefore re-assigning the destination address in the 
outer header is not such a bad idea.

Using All_SMF_Routers as a key could be special-cased in the multicast 
forwarding input path. Legacy versions of this code had to decapsulate 
IPIP headers to deal with DVMRP tunnels anyway.

regards,
BMS

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jul 2007 11:20:40 -0700

Comments on this draft follow. By way of disclaimer,
these comments are not to be considered as endorsement
of the protocol's correctness and/or its applicability
for any use-cases.

Fred

1) (semi-substantial) Section 1, first sentence, reference
for "MANET" should be draft-ietf-autoconf-manetarch-04.txt
(which in turn cites RFC2501).

2) (substantial) Section 2, definitions for {interface, MANET
interface, link, symmetric link} need to be squared with
draft-ietf-autoconf-manetarch-04.txt. In particular, there is
a tension between "link" as "a communications facility at a
layer below IP..." (per [MANETARCH], RFCs 2460/2461/2753, etc.),
and "link" as a neighboring relationship between nodes (per this
document) that needs to be harmonized.

Specific suggestion for "link" is:

  "Link
      A communications facility at a layer below IP, over which nodes
      exchange IP packets directly without decrementing IP TTL (Hop
      Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said
      to exists between two nodes X and Y if at least one node is
      heard by the other on the underlying communications facility.
      The term "link" in this document is therefore used to refer to
      the pairwise links between two nodes unless otherwise noted."

3) (semi-substantial) Section 4.1, second bullet, "links to this
MANET interface" makes no sense, because an interface is a node's
attachment to a link; not vice-versa. Change to: "links associated
with this MANET interface".

4) (comment) Section 5.1.1, should: "HELLO_INTERVAL" be called:
"HELLO_MAX_INTERVAL" instead?

5) (semi-substantial) Section 5.1.1, last paragraph, the term
"responsive" is not previously defined and its use here seems
ambiguous, e.g., what exactly is a "responsive HELLO message"?
The term is used in 4 places throughout the document and seems
ambiguous in all 4. Suggest adding "responsive" to terminology.

6) (semi-editorial) Section 6, last sentence of first paragraph,
change: "Two addresses" to: "Two identical addresses".

7) (semi-substantial) Section 7, change: "links to that MANET
interface" to: "links associated with that MANET interface".
(Same comment as 3) above.)

8) (semi-editorial) Section 7, final sentence, same comment
as 6) above.

9) (semi-substantial) Section 15, if this document is to go as
standards-track, "proposed" should be changed to: "recommended".

10) (comment) Section 15.1, does the recommended HELLO_INTERVAL
(HELLO_MAX_INTERVAL?) of 2 seconds relate in any way to the
expected characteristics of the underlying communications
facility? If so, maybe add a sentence saying so.

11) (semi-substantial) Section 17, add [MANETARCH] as normative
reference. 

(end of comments)

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jul 2007 17:31:58 -0700

Comments on this draft (mostly editorial and clarifying
questions) follow. Overall comment is that this all looks
computationally expensive, but I have no way of quantifying.

Fred

1) (semi-editorial) Section 2, the definition for "Address"
seems self-referential and never really specifies exactly
what an "address" is. Since the meaning of "address" is
already well understood in the IETF context and presumably
no different here, suggest dropping the definition.

2) (editorial) Section 3, s/between in/in/

3) (comment) Section 4, is this section really necessary?

4) (comment) Section 5.2 and elsewhere, it strikes me as odd
that the inclusion of optional fields is consistently phrased
in the negative (e.g., noorig, nohoplimit, nohopcount, etc.)
such that setting the bit means that the field is not present.
It results in casting things in a "double-negative", e.g.
noorig=0 means that "there is an orig". Any reason these were 
not phrased in the positive instead?

5) (comment) Section 5.2, a 2-octet <message-size> field
seems excessive, but I guess it is that way for 32-bit
alignment? Otherwise, a flag in <msg-semantics> could be
defined to cast is as either a 1-octet or 2-octet field. 

6) (comment) Section 5.2.1, I'm not seeing the benefit of
requiring all addresses to be the same length (i.e., using
IPv4-mapped IPv6 addresses if necessary). Wouldn't it make more
sense to define an <addr-semantics> bit that specifies whether
an address block contains all-IPv4 or all-IPv6 addresses?

7) (comment) Section 5.3, a fixed <tlvs-length> of 2-octets
seems excessive, but there seems to be no way to shorten
it for TLV blocks that are shorter than 255 bytes?

8) (semi-substantial) Section 5.3.1, bit 0 (hassubtype) has
switched to phrasing an optional field selector bit in the
positive instead of the negative - see 4) above. To be
consistent, it should be renamed as "(nosubtype)" with the
bit definitions adjusted accordingly. (But IMHO, better would
be to phrase all optional field selector bits in the positive.)

9) (comment) Section 5.3.1, under <length>, why is it that:
"If present it MUST NOT be zero.", i.e., it is not immediately
apparent why a <length> of 0 with a null <value> "MUST NOT"
be included?

10) (semi-editorial) Section 5.4, it should be noted that
padding is possible and may be desired for other purposes
than just 32-bit alignment, e.g., padding all messages to
a common size, MTU probing, etc.

(end of comments)

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Fri, 13 Jul 2007 10:02:27 +0100

Thanks for these. Comments inline below with >>> 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: 13 July 2007 01:32
To: manet
Subject: [manet] comments on draft-ietf-manet-packetbb-08.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. 

Fred

>>> This one I don't agree with. Without it, what's the
>>> size of an address?

>>> How many times have I read this and missed that. Thanks.

>>> Here I'd take advice from people more familiar with the
>>> process than I am. The logic was that this is Standards
>>> Track, and people may be expecting a protocol. I'd happily
>>> lose it as long as the IESG or the RFC Editor won't want
>>> it back.

>>> The logic is from the origin. We designed this for OLSRv2,
>>> and only later modified to accommodate others. There is a
>>> "backwards to OLSRv1 partial compatibility" and zero is
>>> that mode, and the mode mandated by OLSRv2.

>>> That is a possibility. We haven't done it as we
>>> haven't seen enough value.

>>> I don't want an IPv4/IPv6 bit because there is always the
>>> possibility of using this structure for other address
>>> sizes. And really I'm not seeing this as a real need.
>>> How often do we actually mix the two in a single MANET?
>>> Also the originator address needs a length.

>>> I have come up with two (I think) nasty ways of doing
>>> it, but they add to the complexity (especially the
>>> parsing complexity) of the specification, for what I
>>> haven't viewed as enough win.

>>> Here I expect the overwhelming majority of uses to be
>>> without a subtype (it was debateable whether to even add
>>> subtypes) so again the logic is zer = default.

>>> That's a good point. We don't protect against inefficiency
>>> in other places (e.g. you can set both indexes to the same
>>> value rather than use singleindex) so why here.

>>> Now that's actually the first good thing I've heard
>>> about padding. I've never been convinced of its real
>>> value. But somebody wanted it, and it was painless in
>>> both definition and implementation, so it went in.

********************************************************************
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: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Fri, 13 Jul 2007 10:21:14 +0100

Thanks again, and inline comments >>> 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: 12 July 2007 19:21
To: manet
Subject: [manet] comments on draft-ietf-manet-nhdp-04.txt

               *** WARNING ***

Fred

>>> We haven't done this, because this is Standards Track,
>>> and that's still only an ID. If it were an RFC (i.e.
>>> been accepted) I'd happily reference it. But I'm not
>>> sure right now. This we will need to discuss.

  "Link

>>> This one I want to think about. But I don't feel that we
>>> automatically have to follow manetarch if it causes us
>>> problems here. And that's much too detailed for how we
>>> need the word here, and is inconsistent with it - that
>>> definition has a link between nodes, we have (and must
>>> have) a link as between MANET interfaces.

>>> That's not right, because it loses the "to". We only record
>>> links which are to us, or to and from us (or lost examples
>>> thereof).

>>> No. Too cumbersome, and HELLO_INTERVAL isn't just the
>>> maximum, in normal operation when nothing is changing
>>> it is the HELLO interval.

>>> See Section 4.3.1, second and third bullets.

>>> I see your point, but that actual change doesn't work for
>>> me, as at this point what is "identical"? I think if it's
>>> necessary to change that sentence (borderline in my
>>> opinion) that's not the change I'd make.

>>> And see my comment above.

>>> Ditto.

>>> Thanks.

>>> It must (which is I think why we have had the proposed there).
>>> There should be something.

>>> See above, I'm not entirely happy with this.

(end of comments)

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Jul 2007 09:21:54 -0700

Chris,

Thanks for your response, and pls see my folloups below:

Fred

> From: Dearlove, Christopher (UK) 
> [mailto:[email-masked]] 
> Sent: Friday, July 13, 2007 2:02 AM
> To: Templin, Fred L; manet
> Subject: RE: [manet] comments on draft-ietf-manet-packetbb-08.txt
> 
> 

I understand your point, but I don't believe (re)defining
"address" under Terminolgy is the correct way to capture it. 
IMHO it should be captured in normative text of the document
instead, and you alreay do this in Section 3 where it says:

  "All addresses within a control message are assumed to be of
   the same size, deduced from IP.  In the case of mixed IPv6 and IPv4
   addresses, IPv4 addresses are represented as IPv4-mapped IPv6
   addresses as specified in [2]."

So, (re)defining "address" under terminology is IMHO redundant
and potentially confusing.  
 
> >>> How many times have I read this and missed that. Thanks.

OK. This was the only one of its ilk that I found, so
it seems like this has been proof-read many times over.
 
> >>> lose it as long as the IESG or the RFC Editor won't want

OK on getting advice from IESG/RFC Editor. Maybe bring
up during AUTH48?
 
> >>> that mode, and the mode mandated by OLSRv2.

I won't press the point, but it still seems odd to me.
 
> >>> haven't seen enough value.

It could be argued that you've jumped through many other
complicated hoops for indeterminate value, so why not
this one too?

> >>> sizes.

OK.

> >>> And really I'm not seeing this as a real need.

Never say never.

> >>> Also the originator address needs a length.

OK to leave this one as already documented.
 
> >>> haven't viewed as enough win.

But, would it be any more complex than some of the other
hoops you are already jumping through, i.e., where do you
draw the line?
 
> >>> subtypes) so again the logic is zer = default.

If we allow your explanation for 4) (which I am willing
to do), then I would prefer to see this as "(nosubtype)".
If we still disagree, then you're the one with the pen
and I'm the one who gets to go off and grumble. 

> >>> value rather than use singleindex) so why here.

OK.

> >>> both definition and implementation, so it went in.

OK.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Jul 2007 10:07:04 -0700

Chris - pls see my followups below:

Fred

> Sent: Friday, July 13, 2007 2:21 AM
> Subject: RE: [manet] comments on draft-ietf-manet-nhdp-04.txt
> 
> 

I am sure you have already guessed my response, but the
document already cites four works in progress so why not
this one too - especially since it presumably documents
*the* MANET Architecture.
 
> >>> problems here.

The first part of the definition could cite RFC{2460,2461,3753}
instead, but [MANETARCH] would seem more appropriate.
 
> >>> And that's much too detailed for how we

The issue here is that there is a disparity between the two
uses of the term "link" that needs to be resolved to avoid
ambiguity. Perhaps you would be more amenable to the following
slight re-wording of the proposal:

  "Link
      A communications facility at a layer below IP, over which nodes
      exchange IP packets directly without decrementing IP TTL (Hop
      Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said
      to exist between two MANET interfaces if at least one interface
      is heard by the other. The term "link" in this document is
      therefore used to refer to the pairwise links between two
      MANET interfaces unless otherwise noted."

> >>> links which are to us, or to and from us (or lost examples

OK to leave this one alone.

OK.
 
> >>> See Section 4.3.1, second and third bullets.

That doesn't quite do it for me. What would work would be
to change: "As a response," to: "Responsively," in the
second bullet.
 
> >>> opinion) that's not the change I'd make.

How about:

  "Two addresses are considered equal if and only if they match
   and their associated prefix lengths are also equal."
 
> >>> And see my comment above.

Acceptable.
 
> 8) (semi-editorial) Section 7, final sentence, same comment

See above.

OK.

OK.
 
> >>> See above, I'm not entirely happy with this.

Actually, since [MANETARCH] is going as Informational, perhaps
citing as informative is sufficient?

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 16 Jul 2007 09:47:22 +0100

> *the* MANET Architecture.

The difference is that we can be pretty confident that the
others will progress to RFC before or at the same time as
this one - three because they are from the same authors,
and the IANA draft because it's simple and I'm confident
it will go into the process soon. Manetarch we don't have
that control over, and it's not as close to final. But I
would like to be referencing manetarch, though not if it
causes delay (e.g. if by putting it in we are forced to
wait for it to be published, and something causes a serious
delay). So at the moment it's not in, but we also would
like to put it in, and I for one need to consult on this.

> slight re-wording of the proposal:

Closer, but we need to consider directionality. At the moment
can we agree to reconsider the definition of link, without
coming to a firm decision on it. (Actually that applies to
all of Fred's comments. You're getting my responses, but I'm
not the only author. We'll be collecting together all the
responses we get - including some of our own - and going
through them.

> to change: "As a response," to: "Responsively," in the

I need to check the grammar (I don't have it in front of me)
but that sounds like a good idea.
 
> and their associated prefix lengths are also equal."

That I like.

> citing as informative is sufficient?

Could be.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 16 Jul 2007 11:39:15 +0100

> instead, and you alreay do this in Section 3 where it says:

<snipped>

> and potentially confusing.

I don't see it as confusing, but potentially redundant, OK.
There is an issue that without this in the terminology, the
variable address-length is arguably not well-defined here (at
this point someone may say "what about a mixture?" - it's
answered later). On the "think about" list.

> hoops you are already jumping through, i.e., where do you

Note that there is interaction between this and the single
octet length (you can't have a TLV block longer than the
message it's in) and then you are in the nasty situation
of flags in one structure defining the state of another
structure. My code (but of course others may do something
quite different) has an OO packetbb parser, and packet
builder and this (the latter especially) gets ugly here.

Where you draw the line is a very good question, and I'm
conscious that the line is not where various people would
put it. Problem is, some want to move it to the left, others
to the right, and yet more just want it nailed down somewhere
as soon as possible.