Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-07.txt

From: [email-masked]
Date: Sat, 07 Mar 2015 02:10:38 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

        Title           : Dynamic MANET On-demand (AODVv2) Routing
        Authors         : Charles E. Perkins
                          Stan Ratliff
                          John Dowdell
                          Lotte Steenbrink
                          Victoria Mercieca
	Filename        : draft-ietf-manet-aodvv2-07.txt
	Pages           : 85
	Date            : 2015-03-07

Abstract:
   The revised Ad Hoc On-demand Distance Vector (AODVv2) routing
   protocol is intended for use by mobile routers in wireless, multihop
   networks.  AODVv2 determines unicast routes among AODVv2 routers
   within the network in an on-demand fashion, offering rapid
   convergence in dynamic topologies.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-aodvv2-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 10 Mar 2015 14:12:15 +0000

I'm planning to read all of this draft, but as you might expect, I've first taken a particular look at Section 10, which is all I comment on here. There's one small but definite error, and I'll make other comments.

First paragraph, "but, in line ... RFC5444 packet". This is true, but it might be considered that there's an implication that AODVv2 could do that if it wanted to, which it can't when following the RFC5498 imposed model.

First paragraph "the parser ... forwarding". I wouldn't characterise what's being described here as a function of "the parser". The mandated (by RFC 5498) architecture is that there's an RFC 5444 multiplexer that takes the packet and distributes the messages in it to the protocols that want them (and makes packet header available). It's an implementation issue whether it does all the parsing and distributes some sort of structure to each, or distributes the block of octets (or some other option I've not thought of) making each protocol do its own parsing (presumably using a common library). I think all the RFC5444 implementations I've heard of do the former, but RFC5444 doesn't impose that. And they all use different structures. However the issue of known and unknown TLVs only comes in at the protocol - if you do the parsing in the multiplexer you probably (I've not heard of anyone doing otherwise) have no idea which TLVs are known or unknown. I think a common approach is simply parse everything, then the protocol ignores unknown TLVs by simply just not looking for them. So (getting to my point) in the architectures I'm aware of it's not the parser that "SHOULD ignore the information for processing" but the protocol looking at the parsed information. Of course I'm not saying that's how it must be done, just rather that it's potentially confusing to describe this as being done by the parser.

List, third point. (Incidentally I'd bullet or number these.) "Each address block MAY also have one or more associated TLV blocks;". No. Each address block has exactly one associated TLV block. It may contain any number of TLVs, including zero. (An empty TLV block simply consists of two zero octets.)

After table "If a packet ...". That's slightly misleading. AODVv2's role here is to indicate what it wants/uses in the packet header. It would, I think, be clearer to just say AODVv2 neither requires any inclusion nor uses any information from the packet header (if that is the case).

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

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

********************************************************************
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: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 10 Mar 2015 14:23:34 +0000

Christopher, 

Thanks for that input! We'll see what we can do to make the draft better. 

Regards,
Stan

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Dearlove,
> Christopher (UK)
> Sent: Tuesday, March 10, 2015 10:12 AM
> To: [email-masked]
> Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-07.txt
> 
> I'm planning to read all of this draft, but as you might expect, I've first taken a
> particular look at Section 10, which is all I comment on here. There's one small
> but definite error, and I'll make other comments.
> 
> First paragraph, "but, in line ... RFC5444 packet". This is true, but it might be
> considered that there's an implication that AODVv2 could do that if it wanted
> to, which it can't when following the RFC5498 imposed model.
> 
> First paragraph "the parser ... forwarding". I wouldn't characterise what's
> being described here as a function of "the parser". The mandated (by RFC
> 5498) architecture is that there's an RFC 5444 multiplexer that takes the
> packet and distributes the messages in it to the protocols that want them
> (and makes packet header available). It's an implementation issue whether it
> does all the parsing and distributes some sort of structure to each, or
> distributes the block of octets (or some other option I've not thought of)
> making each protocol do its own parsing (presumably using a common
> library). I think all the RFC5444 implementations I've heard of do the former,
> but RFC5444 doesn't impose that. And they all use different structures.
> However the issue of known and unknown TLVs only comes in at the
> protocol - if you do the parsing in the multiplexer you probably (I've not
> heard of anyone doing otherwise) have no idea which TLVs are known or
> unknown. I think a common approach is simply parse everything, then the
> protocol ignores unknown TLVs by simply just not looking for them. So
> (getting to my point) in the architectures I'm aware of it's not the parser that
> "SHOULD ignore the information for processing" but the protocol looking at
> the parsed information. Of course I'm not saying that's how it must be done,
> just rather that it's potentially confusing to describe this as being done by the
> parser.
> 
> List, third point. (Incidentally I'd bullet or number these.) "Each address block
> MAY also have one or more associated TLV blocks;". No. Each address block
> has exactly one associated TLV block. It may contain any number of TLVs,
> including zero. (An empty TLV block simply consists of two zero octets.)
> 
> After table "If a packet ...". That's slightly misleading. AODVv2's role here is to
> indicate what it wants/uses in the packet header. It would, I think, be clearer
> to just say AODVv2 neither requires any inclusion nor uses any information
> from the packet header (if that is the case).
> 
> --
> Christopher Dearlove
> Senior Principal Engineer, Information Assurance Group Communications,
> Networks and Image Analysis Capability BAE Systems Advanced Technology
> Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124 [email-masked]
> | http://www.baesystems.com
> 
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales
> No: 1996687
> 
> 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.
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 24 Mar 2015 20:35:36 -0700

Hello Chris,

Basically, I have replaced the word "parser" by "multiplexer".  I think 
this addresses
your points in the explanations below.  I don't think there is anything 
more that
AODVv2 has to do here.  And I used a numbered list as well as the sentence
constructions you suggested in the last two points.

Regards,
Charlie P.