Subject: [manet] draft-ietf-manet-smf-09.txt - WGLC

From: Ian Chakeres <[email-masked]>
Date: Sat, 8 Aug 2009 09:04:39 -0400

This note announces the WG Last Call for comments on draft-ietf-manet- 
smf-09.txt, "Simplified Multicast Forwarding".

The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt

The document is intended to be submitted for publication as an  
experimental standard document.

Please review the document carefully and send your comments to the  
MANET list and document authors.

This last call ends Sunday August 23.

Thanks,
Ian Chakeres

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Aug 2009 17:07:35 +0100

I haven't read every paragraph thoroughly, and I have still
to read the appendices (in this draft) but I thought I'd
send my initial comments.

The document is a (substantial) collection of mechanism, not
a single protocol, with limited interoperability of options.
I'm just going to note that and consider that as a design=
decision. I don't know whether the IESG may have comments on
this and related mattters.

References to RFC 2901 should be to RFC 2501.

Section 2.1 table would be better in alphabetical order.

Should section 3 note that e.g. IGMP can be used unchanged
(assuming that it can - if not, why not?).

Second (last) paragraph of section 3 is one place (there are
others, I think I may note another below) where there is a
reference to demonstrations etc. There are however no details,
ideally an external reference, or at least who did them (if
the authors, I guess a blanket comment to that effect might
work - or is this assumed?).

Section 4 I found the terminology of "SMF forwarder"
confusing. There are nodes (routers) participating in SMF.
At any given time a node may forward all (subject to DPD),
some or none of the packets it receives. I think this still
classifies the latter as an SMF forwarder, where my first
assumption was that they were excluded. I would suggest
"SMF participant".

Section 4, use of site-local address. As these are deprecated,
that's a hostage to IESG fortune.

TTL or hop limit (not count) in Section 4.

Section 4, six point list. Is point 4 in scope for an IETF
protocol?

Section 4 paragraph starting "Note that rule #3" doesn't
make the point that this mechanism avoids the need for a
node to keep a list of its own packets.

Section 5.1.1 "TBD". I would recomment keeping the TBDs
confined solely to the IANA section. I think that's usual
practice.

Section 5.1.3 I made a note of why MD5, and then read later.
Limiting to this section (the subject comes up again later)
my reaction was OK, but here you don't care about that MD5
is weak, but in the forwarding section you take some care
over changed TTLs.

Section 5.3 first paragraph. On my reading so far I don't
understandhow this works. Is it relying on a shared secret
(numerical or procedural) among nodes that an attacker is
assumed not to have? Maybe I need to read better, or maybe
needs some clarification.

Section 6 third paragraph is another case where whose
experiments etc. is a question. In the following 4 point
list Better probably should be better.

Section 7 I spotted an [MDA07] without a space before. Of
course this and other nits will get pciked up later, but
as I spotted it ...

Section 7.1.1 May I suggest Expert Review may suit your
purposes better than STD action, especially for an
Experimental protocol. We looked at all these issues
when finalising RFC 5444 and definitely preferred as
suggested. Expert Review needs criteris - but you can
reference or steal from RFC 5444.

Suggest in describing TLVs you explicitly note that when
a TLV (SMF_NBR_RELAY_ALG) doesn't need parameters you can
omit length/value to avoid this appearing to mandate them.

I would remove all uses of "packetbb". That was only the
working name of RFC 5444, which does not contain that name
at all, so packetbb has no referent. (In section 7 and
IANA section at least.)

Section 8.1 last sentence. My reaction is that by the time
you publish you should know if more work is needed or not.

Section 12 driect -> direct

References, you don't need "and et al" as et means and,
so et al will do.

As I noted, Appendices, not yet. And if I have time I may
go back over some points in what I've covered above. Or
may not.

-- 
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: [email-masked] [mailto:[email-masked]] On Behalf
Of Ian Chakeres
Sent: 08 August 2009 14:05
To: MANET IETF
Subject: [manet] draft-ietf-manet-smf-09.txt - WGLC

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt

Thanks,
Ian Chakeres
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

********************************************************************
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: "joseph.macker" <[email-masked]>
Date: Mon, 10 Aug 2009 13:01:42 -0400

Chris good comments most to incorporate in revision some I will  
respond to in a day or so .. Traveling right Now

Sent from my iPod

On Aug 10, 2009, at 12:07 PM, "Dearlove, Christopher (UK)" <[email-masked] 
 > wrote:

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 11 Aug 2009 10:38:28 +0100

One quick comment on Appendix B (which I have still only
skimmed). Most references are to [OLSRv2], which is correct
(but of course still a moving target). There are some
references to [RFC3626] that aren't clear why the change,
and at least one incorrect reference to [REFC3626] referring
to TLVs (that aren't in it, only in OLSRv2).

I suggest an initial reference to [OLSRv2], with a comment
that the MPR mechanism in it derives from [REFC3626] and
then using [OLSRv2] references thereafter.

-----Original Message-----

                    *** WARNING ***

Thanks,
Ian Chakeres

---

From: jacquet <[email-masked]>
Date: Sun, 23 Aug 2009 22:09:10 +0200

Below are our comment from Pascale Minet and myself about  draft-ietf- 
manet-smf-09.txt

First, general comment: we second the suggestion that has already done  
by many that t NHDP draft should go to WGLC first, since it is an  
important normative reference of draft-ietf-manet-smf-09.txt.

Second, detailed comments:

1. It is not clear how the I-DPD and the H-DPD methods can coexist in  
the same MANET deployment (section 5.2)

2. Could you please specify which type of multicast is supported,  
depending on the two following criteria:
- The multicast source belongs to the MANET or not,
- Some destination nodes are within the MANET and other are outside,....

3. Concerning the group membership protocol, IGMP, it seems that there  
are some problems with this protocol when applied in a MANET. More  
precisely, the elimination procedure between routers that hear each  
other could prevent a host to receive multicast data as illustrated by  
the following example. Two routers R1 and R2 hear each other;  
according to the elimination procedure, only router R1 will send  
queries. There is a host H in the coverage area of R2, but not in the  
coverage area of R1. This host H will never send its report because it  
will never receive a query.

About the appendices.

4. E-CDS does not have a regular reference. Maybe you could use RFC  
5614, or the paper of Wu Dai on rule k CDS.

5. CF SMF forwarder not defined.

6. Although the need is not necessarily obvious, maybe there should be  
some provision about the use of link metrics on relay set selection.

7. In E-CDS: the use of degree node as priority makes the highest  
degree node very busy since it has to forward from many neighbors.

8. Step 8 in E-CDS selection: 1-hop neighbors of node x are not all  
known by node n0. Maybe change it in "1-hop neighbors of node x that  
are in N1 when x is in N2, and all 1-hop neighbors excluding n0 when x  
is in N1". It may be preferable to use the exact terminology of NHDP  
database in order to remove possible confusion.

9. E-CDS selection: router ID and node priority of nodes in N2 should  
be known. This is not clear with NHDP databases, this would need that  
each node advertize the router ID and priority of all its neighbors   
on all its interface, this may be expensive. Maybe it would be less  
burden to remove the possibility of populating Q with node in N2 (I  
think it does not change the performance drastically) and restrict Q  
to N1 nodes only.

10. E-CDS Extension to k-hop as claimed by the document is unclear.

11. Appendix B: S-MPR forwarding rule: notice that S-MPR will still  
work if one allows forwarding from non symmetric neighbors. In this  
case S-MPR nodes can be mixed with non SMF nodes that are not  
performing NHDP, by considering those node as default relay selectors.

12. More general comment: S-MPR operations are described in a per  
interface basis. Why it is not the case with E-CDS? If one interface  
is slow, not reliable but long range, then  E-CDS may be limited to  
the low performance of this interface. Same problem may apply to MPR- 
CDS.

Best regards,
Pascale and Philippe

Le 8 août 09 à 15:04, Ian Chakeres a écrit :

> This note announces the WG Last Call for comments on draft-ietf- 
> manet-smf-09.txt, "Simplified Multicast Forwarding".
>

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 28 Aug 2009 01:05:21 +0200

I know I am late.
But here some remarks, up to page 14.
I may do the rest next week.

Page 7:
>  SMF relies on the MANET NHDP
>  specification to assist in IP layer 2-hop neighborhood state
>  discovery and maintenance for relay set election.
I think NHDP is just one of the options. It is "may rely" instead of
"relies".
Or is sending SMF_TYPE via NHDP mandatory ?? This would require rewording.

General:
What is the expected behavior when SMF nodes with different SMF_RELAY_ALG 
appears in the same network?

page 8:
>  It is important that SMF deployments in
>  localized edge network settings are able to connect and interoperate
>  with existing standard multicast protocols operating within more
>  conventional Internet infrastructures. 
Is SMF limited to edge networks? If so (I think so), this should be 
emphasized in the applicability statement section.
Questions would be: can the SMF enabled MANET act as transit between
other multicast routing domains? If so, are there limitations?

Page 9:
>  SMF
>  implementations MUST be capable of forwarding "global scope"
>  multicast packets to support generic multicast application needs or
>  to distribute designated multicast traffic ingressing the MANET
>  routing region via border routers.
I think there is a broader range of scopes than "global scope" 
(e.g. admin/site/org).

Page 9:
>  There
>  will also be a well-known multicast group for flooding to all SMF
>  forwarders.  This multicast group is specified to contain all MANET
>  SMF routers of a connected MANET routing region, so that packets
>  transmitted to the multicast address associated with the group will
>  be delivered to all connected SMF routers.  For IPv6, the multicast
>  address is specified to be "site-local".  The name of the multicast
>  group is "SL-MANET-ROUTERS".
Do we request for a well known group address?
If yes, do we need to request this in the IANA section?

Page 9:
>  2.  Link local multicast packets MUST NOT be forwarded.
This also applies to Interface-Local. Well known, of course.

Page 10:
>  For example, one class of forwarding is based upon relay
>  set election status and the packet's previous hop forwarder,
On the IP layer, there is no previous hop forwarder. One way of 
getting the required information is using sub-IP layer addresses. 
If so, add some words on this?

Page 11:
>  Similarly, for H-DPD, it is expected that
>  packet hash values will be kept with respect to at least the source
>  address to help ensure hash collision avoidance.
Not sure on if this really helps.

Page 12:
>  "H-bit"
I prefer the H bit depicted in figure 2. Now, it is depicted as "0".
In figure 3, it is also "0", but the H-bit was set.

Page 13:
>  When the "TaggerId" field is not present, then it is
>  assumed the source host applied the SMF-DPD option and the
>  <Identifier> can be considered unique in the context of the IPv6
>  packet header <srcAddr:dstAddr> tuple.
So it is not allowed to not adding a TaggerId on a border router? 
Maybe this is for reasons, what are those? Allow not adding TaggerId 
when not applicable?
When TaggerId is part of Identifier, the TidTyp and TidLen are not 
needed and the 7 bits are freed. And the H-bit is not needed anymore.
If reje

Page 14:
>  | Present     | *        | Present   | Invalid, do not Forward     |
>  | Not Present | Present  | Present   | Invalid, do not Forward     |
These lines are below a wildcard. A sequential lookup in the table 
will not touch the actions for these.

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens Ian
|Chakeres
|Verzonden: zaterdag 8 augustus 2009 15:05
|Aan: MANET IETF
|Onderwerp: [manet] draft-ietf-manet-smf-09.txt - WGLC
|
|This note announces the WG Last Call for comments on draft-ietf-manet-
|smf-09.txt, "Simplified Multicast Forwarding".
|
|The document can be found at: http://www.ietf.org/internet-drafts/draft-
|ietf-manet-smf-09.txt
|
|The document is intended to be submitted for publication as an
|experimental standard document.
|
|Please review the document carefully and send your comments to the
|MANET list and document authors.
|
|This last call ends Sunday August 23.
|
|Thanks,
|Ian Chakeres
|_______________________________________________
|manet mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/manet