RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt

["Templin, Fred L" <[e-mail]>]

> -----Original Message-----
> From: Thomas Narten [mailto:[e-mail]] 
> Sent: Tuesday, December 04, 2007 5:44 AM
> To: [e-mail]
> Subject: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt
> 
> 2007-11-30 review of -7
> 
> Overall. I still do not think this document is ready for
> publication. It is still to vague/muddy on the key architectural
> points  that it is supposed to explain.
> 
> My major concern is that you still do not lay out an understandable
> "architecture" that allows one to understand what an IP subnet would
> look like in MANETs.
> 
> Interface terminology is non-standard and confusing. Should use "link
> type". Really. If you want the rest of the community to be able to
> understand this stuff, you cannot redefine terminology that is already
> widely in use and understood to mean something different than who it
> is used in this document.

I agree with Thomas, and I believe also confirmed by Teco.
IMHO, this is an INT area document (not RTG) and it needs
to speak to the terminology of the INT area.

Thanks - Fred
[e-mail]
 
> 
>    Neighbor
>       In the context of routing, two routers are neighbors if one can
>       send/receive routing protocol IP packets to the other without
>       passing through any intermediaries at the same layer.
> 
> Why "router"? Definition of neighbor from from 2460 should be used
> instead:
> 
>    neighbors   - nodes attached to the same link.
> 
> Why (or why isn't) the RFC2460 definition sufficient?
> 
>    Interface
>       A node's point of attachment to a communication link.
> 
> This is mostly fine as written, but...
> 
>    Semi-Broadcast Interface (SBI)
>       A broadcast capable interface that may exhibit asymmetric
>       reachability.  Multiple access wireless radio 
> interfaces are often
>       SBI.  Note that since a SBI *may* exhibit asymmetric 
> reachability,
>       it also may not.
> 
> Call it a "link" not an "interface".
> 
> Manets provide IP with a conceptual link, that has certain
> properties. What I thought the MANET architecture would provide is a
> description of the properties of that link type.
> 
>    MANET Interface
>       A MANET interface is distinguished by its potentially 
> significant
>       time-varying asymmetric reachability (e.g., SBI) 
> amongst potential
>       neighboring routers.  A more detailed discussion of MANET
>       interface characteristics is presented in Section 4.2.  The
>       addressing constraints for a MANET interface are discussed in
>       Section 5.2.
> 
> No. A MANET _link_ has these characteristics. Not the interface.
> 
> Etc.
> 
>    MANET Router (MNR)
>       A MANET router is distinguished by having one or more MANET
>       interfaces.  A MANET router may also have zero or more non-MANET
>       interfaces.  A MANET router is responsible for hiding MANETs'
>       challenging characteristics from nodes that are not MANET-aware.
>       A MANET router with a single MANET interface is illustrated in
>       Figure 1.
> 
> No. the "interface/link" hides the challenging characteristics from
> IP. Not the BR itself. This is a critical point (architecturally) to
> get right.
> 
> You really (I think) need to define an abstraction that defines an
> link type of "manet" that handles all the "interesting"
> characteristics of MANETs (like non-transitive connectivity) but that
> also presents itself to IP as a single IP subnet that has the normal
> properties.
> 
>    MANET Neighborhood
>       a set of neighboring routers that can communicate via MANET
>       interfaces without passing through any other routers
>       (intermediaries at the same layer).
> 
> If A can reach B, B can reach C, but A cannot reach C, are A&C in the
> same neighborhood? from the wording, I think the answer is no, per the
> definition of "neighbor". Do I understand that correctly? 
> 
>    MANET
>       a routing domain containing MANET routers.  A example MANET is
>       illustrated in Figure 3.
> 
> This is too vague (i.e, it's a meangless definition). If I have two
> manet routers connected to each other, plus 100 ethernet links
> connected by routers, is the entire set considered to be part the
> "MANET"?
> 
>    receive the packet from PR1 on its interface and determine that it
>    must retransmit the packet over the same interface as the one where
>    the packet was received, in order for the packet to reach 
> PR3.  From
> 
> s/retransmit/forward/
> 
>    Wireless interfaces often exhibit more challenging characteristics
>    when compared to wired interfaces.  Many protocols (e.g., IPv6
>    neighbor discovery [RFC4861]) were not designed to operate in
>    wireless networks with asymmetric reachability.  Wireless 
> interfaces
>    may also exhibit very dynamic time varying performance 
> (e.g., packet
>    loss, data rate), and the factors have a significant 
> impact on local
>    communication.
> 
> 
> Be more precise. ND assumes  a standard IP subnet model that all nodes
> on the same subnet are neighbors.
> 
> Also, it is wrong to say "wireless vs. wired". What you really mean is
> that the link characteristics of things like typical ethernet differ
> from the link characteristics of other technologies.
> 
> The challenge for MANETs is to figure out how to work around that
> assumption.
> 
>    Ad hoc networking further compounds problems by allowing nodes to
>    join and leave the network, or even form new networks, at will.
> 
> Do you mean "links"? or "subnets"? Saying "network" is vague.
> 
> 4.2.  Challenges
> 
>    MANET characteristics result in many challenges.  These challenges
>    reveal themselves in many forms, and MANET specific protocols must
>    often be developed.
> 
> I don't like this wording. what is unclear here is _what_ protocols
> will need to do this, and to what degree these are MANET-specific
> (hidden under an abstraction of an interface looking like a normal IP
> subnet, with emulation underneath to deal with the manet challenges)
> or something else.
> 
>    In MANETs' with SBI, MANET routers within the same small geographic
>    region are often densely connected with other nearby MANET routers.
>    These routers form a set of extended neighbor relationships.  This
>    set is referred to as a MANET neighborhood.  A MANET 
> neighborhood is
>    typically composed of several MANET routers, with each MANET router
>    being densely connected to other MANET routers.
> 
> Shouldn't this be in the defintion section?
> 
>    logical.  For example, in an Ethernet network nodes are often told
>    that a particular range of addresses are "on-link".  In MANETs' a
>    MANET router often cannot make assumptions that a particular set of
>    MANET routers is always (directly) reachable.  Instead, 
> MANET routers
>    must detect and determine neighboring MANET routers, and handle
>    changes to this set over time.
> 
> Again, I find the term "MR" vague here. The issues here have to do
> with MANET-specific things, and refer only to the MANET links. Yet,
> the MR definition is broader, and simply says "a router with at least
> one interface to a MANET".
> 
> I would expect section 5.2 to clarify what the basic MANET subnet
> model is. But it does not.
> 
>    Unique Prefixes
>       MANET interfaces that are known to exhibit the above mentioned
>       properties must be configured with unique prefixes.  The reason
>       for this requirements is so that no two MANET interfaces are
>       configured to appear within the same IP prefix.  One way to
>       achieve this is /128 (IPv6) or /32 (IPv4) prefixes.  It is worth
>       noting that prefix lengths shorter than /128 (IPv6) or 
> /32 (IPv4)
>       are possible on the MANET interfaces, as long as the 
> prefixes are
>       unique to a single MANET interface.  Note that the above
>       statements are not an exception, but simply a clarification that
>       MANET are no different from other networks in this respect.
> 
> 
> Don't understand this. More specifically:
> 
>       MANET interfaces that are known to exhibit the above mentioned
>       properties must be configured with unique prefixes.  The reason
>       for this requirements is so that no two MANET interfaces are
>       configured to appear within the same IP prefix.
> 
> Why? Is this a requirement specific to MANETs, or is this a more
> general requirement?
> 
>       One way to
>       achieve this is /128 (IPv6) or /32 (IPv4) prefixes.  It is worth
>       noting that prefix lengths shorter than /128 (IPv6) or /32
>       (IPv4)
> 
> Sorry, but a /128 or /32 is an address, not a prefix (practically
> speaking). If you really mean "an address", why don't you say so. 
>       
>       are possible on the MANET interfaces, as long as the 
> prefixes are
>       unique to a single MANET interface.  Note that the above
>       statements are not an exception, but simply a clarification that
>       MANET are no different from other networks in this respect.
> 
> If this is really a standard requirement of IP, I still don't get what
> issue you are trying to raise or why you are point this out.      
> 
> Link-local Multicast/Broadcast Scope
>       On a MANET interface, a packet sent to a link-local multicast or
>       all-ones broadcast address reaches the MANET interfaces of
>       neighboring MANET routers, regardless of their configured
>       addresses.  Link-local multicast/broadcast packets are never
>       forwarded and since a MANET may span several hops, nodes cannot
>       assume that a packet sent to a link-local multicast/broadcast
>       address will reach all routers within a MANET.
> 
> Sorry, this is bogus. "link-local multicast" is defined by IP and
> means that a packet sent to that address is delivered to all nodes on
> the "link". This latter part, that says "never forwarded" does not
> make sense.  They are never forwarded beyond the link, but they may be
> forwarded by MRs (your terminology) if required by the "link
> model". You cannot just say that multicast doesn't work in MANETS, and
> then imply protocols at the IP  layer need to take that into
> account. That would be changing the basic IP model.
> 
> 
> 
> Thomas
> 
> 
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/autoconf
> 


_______________________________________________
Autoconf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/autoconf