[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] REVIEWS NEEDED: draft-ietf-dna-network
On Wednesday 05 July 2006 00:25, Suresh Krishnan wrote:
> Hi Folks,
> The DNA routers draft (renamed to draft-ietf-dna-network-00) is
> ready to be last called before being sent to the IESG for
> publication. Please take some time to read the draft and respond to
> the mailing list with your reviews.
Folks,
I reviewed the draft and I have some comments. Not being a native
English speaker, apologize if some of the editorial suggestions don't
make sense. I thought the draft was in very good shape; Most of my
comments are editorial.
I have two suggestions which apply to the entire draft:
- The document always refer to hosts, as opposed to routers. I
understand the point, but now that we have NEMO and mobile
routers, what about replacing everywhere host by node? that
would still maintain a difference between nodes and router which
I assume is what is wanted.
- For consistency with RFC2461, I suggest replacing everywhere
neighbour with neighbor.
Then throughout the draft:
> Abstract
>
> Hosts experiencing rapid link-layer changes may require to do
> configuration change detection procedures more frequently than
> traditional fixed hosts. This document describes practices
> available to network deployers in order to support such hosts in
> Detecting Network Attachment in IPv6 networks.
Suggest to rephrase as:
Mobile nodes experiencing rapid link-layer changes may have to
detect configuration change more frequently than fixed hosts.
This document describes practices for network deployers to support
such nodes in Detecting Network Attachment in IPv6 networks.
> 1. Introduction
>
> Hosts on the Internet may be connected by various media. It has
> become common that hosts have access through wireless media and
> are mobile. The frequency of configuration change for wireless
> and nomadic devices are elevated, due to the vagaries of wireless
> propagation or the motion of the hosts themselves.
Suggest to rephrase as:
Nodes on the Internet are connected by various media. Nowadays it
is common that nodes are mobile and access Internet through
wireless media. The frequency of configuration changes for
wireless and nomadic devices is elevated, due to the vagaries of
wireless propagation or the motion of the hosts themselves.
> Such hosts need to determine if they have moved to a new IPv6
> link rapidly, in order that configuration procedures may be run
> and application packet delivery services restored. Detecting
> Network Attachment (DNA) is a strategy to assist such
> configuration changes by rapidly determining whether they are
> required.
Suggest to rephrase as:
Such nodes need to quickly determine if they have moved to a new
IPv6 link, so that they can start reconfiguration procedures and
restore packet delivery to applications. Detecting Network
Attachment (DNA) is a strategy to assist such reconfiguration
procedures by rapidly determining whether they are required.
>
> [...]
>
> It should be noted that many already deployed routers will not
> support these recommendations, and that hosts SHOULD NOT rely on
> their being in place, unless they have particular reason to do
> so.
Suggest to rephrase as:
It should be noted that many routers already deployed will not
support these recommendations. Therefore, nodes SHOULD NOT rely on
them being in place unless they have a particular reason to do so.
> 1.1 Terms and Abbreviations
>
> Access network: A network where hosts are present. Especially, a
> network used for the support of visiting wireless hosts.
Suggest to rephrase as:
Access Network: An IP network which has on its edge one or
more routers handling the last hop to mobile nodes, typically
but necessarily over a wireless link
> Link: A link is the range across which communications can pass
> without being forwarded through a router [1].
>
> Link-Change: Link-Change occurs when a host moves from a
> point-of-attachment on a link, to another point-of-attachment
> where it is unable to reach devices belonging to the previous
> link, without being forwarded through a router.
Why not simply have:
Link-Change: Link-Change occurs when a host moves from a
point-of-attachment on a given link to another
point-of-attachment on a different link.
>
> [...]
>
> 2.1 Multicast and Unicast RA Responses
>
> The dis-advantage in sending unicast RA is that the router will
=> The disadvantage [...]
> not be able to aggregate its response for multiple RS messages
=> not be able to aggregate its responses to multiple RS messages
> from multiple hosts received during the waiting period before RA
> transmission. Moreover, using unicast RA to respond to RS
> disables routers' ability to limit the rate of unicast RA.
>
> For multicast Router Advertisements, a minimum separating delay
> exists so that these RAs may not be scheduled close to each other.
=> exists so that these RAs may not be scheduled too close to each
other.
> When a host solicits and attempts to schedule a multicast RA
=> When a host solicits and the router attempts to schedule a
multicast RA
> within MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile
> IPv6 [3]) of the previous multicast Router Advertisement, the
> scheduling of a response will be deferred until the minimum
> separation expires.
>
> [...]
>
> It is noted that computational requirements for SEND may preclude
=> It is noted that computational requirements of SEND may preclude
> this subsequent aggregation in some environments.
>
> [...]
>
> In some cases it is not possible to provide unicast responses,
> since solicitations may be sent with an unspecified address, or
> solicitations do not provide enough link-layer addressing
> information to send an unicast response without neighbour
> discovery exchange. In these cases, a router may need to send
> multicast responses, even if the expected delay is greater.
If the RS was sent from an unspecified address, would it be possible
to send a multicast RA to a unicast link-layer address? (Fred L.
Templin suggested that to me)
> 2.1.1 Recommendations
>
> Routers SHOULD respond to a RS message with unicast RA
> message.
>
> Routers SHOULD aggregate RA messages into a multi-cast RA
=> Routers SHOULD aggregate RA messages into a multicast RA
> message if more than 3 unicast RA messages are queued for
> transmission.
>
> [...]
>
> 2.2 Router Advertisement Parameters
Where hosts often change their link attachment (e.g., because they
=> Where hosts often change their link of attachment...
OR, Where hosts often change their point-of-attachment...
> are mobile), there may be a number of prefixes or routers stored
> in the host's memory, which are no longer directly reachable.
> This additional storage may make movement detection slower where
> hosts rapidly pass through networks, or pass through networks
> which have very long advertised timeouts.
>
> [...]
>
> 3.1 Link Extent and Composition
>
> Most of today's access networks deploy link-layer bridging
> technologies in order to extend their logical range beyond a
=> technologies to extend their logical range beyond a
> single Medium Access Control domain.
>
> Consequently, while many routers will come with traditional wired
> or optic-fibre interfaces, packets travelling within the same link
=> or optic fibre interfaces, packets travelling within the same link
> may have been bridged across from a wired segment to a wireless
> segment.
>
> [...]
>
> 3.2 Multiple Router Links
=> 3.2 Multiple Routers Links
OR, 3.2 Links with Multiple Routers
>
> [...]
>
> 5.1 Providing Router Authorization
>
> In DNA, some hosts will begin configuration procedures based on a
> single message transmitted by a router. As such the ability of
> routing infrastructure to prove its authenticity and authorization
> is important to support correct operation of hosts. Authentication
> and authorization mechanisms exist which allow hosts to check
> security of routers when they receive Router Advertisements
> indicating link change.
The mechanisms mentionned above are SEND, or there are others? If this
is SEND only I suggest citing SEND here, by e.g. rephrasing as:
In DNA, some hosts will begin configuration procedures based on a
single message transmitted by a router. As such the ability of
routing infrastructure to prove its authenticity and authorization
is important to support correct operation of hosts. Secure
Neighbor Discovery (SEND) [4] defines authentication and
authorization mechanisms which allow hosts to check security of
routers when they receive Router Advertisements indicating link
change.
> [...]
>
> Hosts which wish to have secured exchanges with neighbours and on-
> link routers may use Secured Neighbour Discovery (SEND) [4]. SEND
=> link routers may use Secure Neighbour Discovery (SEND) [4]. SEND
(s/Secured/secure/)
> provides authenticity as well as response matching, using nonces
> copied from solicitations into advertisements.
>
> [...]
That's it.
Best,
--julien
--
-- Dr. Ing. Julien H. Laganier
Researcher
DoCoMo Communications Laboratories Europe GmbH
Landsbergerstrasse 312, 80687 Munchen, Deutschland
"So einfach wie m glich. Aber nicht einfacher." -- Albert Einstein
"La perfection est atteinte non quand il ne reste rien à ajouter,
mais quand il ne reste rien à enlever." -- Antoine de Saint-Exupéry
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian W. Kernighan