[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] Review of draft-ietf-dna-link-information-03.txt
Review of draft-ietf-dna-link-information-03.txt
Overall, I think this document has some issues:
a. The document appears to apply to both IPv4 and IPv6, but it makes a
number of statements that do not reflect the operation of DNAv4 as defined
in RFC 4436. For example, DNAv4 does not utilize "link down" events or make
use of link layer "hints".
b. A terminology section is needed, and terminology
consistency needs to be improved. For example the terms
"event notifications" and "link layer events" are used. It
is not clear to me if these are synonymous with terms such
as "triggers" or "link indications" used in other documents.
Similarly, the term "link layer connection" is
used, which may or may not correspond to the term
"link up" used in this and other documents.
c. Normative language is used relating to events without
a tie to the DNA spec. For example, the document requires
that "link down" events be generated prior to a "link up" without
indicating why such events would be helpful. In fact, in DNAv4 these
events will be ignored, and generating such events would actually be
harmful to operating systems or applications that tear down connections on
receipt of "link down" events.
Abstract:
" Certain network access technologies are capable of providing various
link-layer status information to IP. Link-layer event notifications
can help IP expeditiously detect configuration changes. This
document provides a non-exhaustive catalogue of information available
from well-known access technologies."
This abstract does not clearly indicate the purpose of the document. It
would be helpful to state that the primary purpose is to address
events relating to DNAv6 (since the document does not appear to apply to
DNAv4).
Section 1
" Detecting the subnet change can usually use
network-layer indications such as a change in the advertised prefixes
(i.e., appearance and disappearance of prefixes)."
Is this document solely focussed on DNAv6? If IPv4 is in scope, then since
router advertisement is not widely implemented, it should be made clear
that prefixes are just an example. For example, you can change the text
to:
" Detecting the subnet change can usually use
network-layer indications (such as a change in the advertised
prefixes for IPv6)."
"Establishment and
tear down of a link-layer connection are two basic events types.
Additional information can be conveyed in addition to the event type,
such as the identifier of the network attachment point (e.g., IEEE
802.11 BSSID and SSID), or network-layer configuration parameters
obtained via the link-layer attachment process if available. It is
envisaged that such event notifications can in certain circumstances
be used to expedite the inter-subnet movement detection and
reconfiguration process. For example, the notification indicating
that the node has established a new link-layer connection MAY be used
for immediately probing the network for a possible configuration
change. In the absence of such a notification from the link-layer,
IP has to wait for indications that are not immediately available,
such as receipt of next scheduled router advertisement,
unreachability of the default gateway, etc."
The term "link layer connection" is used here, but is not defined.
I am not sure whether this only relates to connection-oriented
link layers, or whether this is synonymous with "link up".
What are "network layer configuration parameters obtained via the
link-layer attachment process"? Perhaps an example would help (e.g. PPP
IPCP)
" Two basic link-layer events are considered potentially useful to DNA
process: link up and link down."
This contradicts RFC 4436, Section 1.3:
"DNAv4 does not utilize "Link Down" indications."
"Each time the interface changes its point of attachment, a
link down event with the previous attachment point MUST be followed
by a link up event with the new one. Finally, when the network
interface is disabled, this MUST generate a link down event. Each
one of these events MUST generate a notification in the order they
occur."
I don't understand the use of normative language here. Given that
link down is not used by DNAv4, why is it relevant to require that
link down events be generated on handoff? Existing operating systems
do not necessarily generate these events because they can be disruptive
to applications.
"While
merely knowing that a new link-layer connection is established may
prompt DNA process to immediately seek other clues for detecting
network configuration change, auxiliary information may constitute
further clues (and even the final answers sometimes)."
DNAv4 does not utilize link-layer information this way. Rather than
utilizing link-layer "hints", in DNAv4, all the active configurations
are probed via ARP.
Section 2.3
"A station (STA) MUST establish
a IEEE 802.11 link with an AP in order to send and receive IP
packets."
I'm not clear why the term "link" is used here (I think this refers to
Association) or why it is normative (presumably the ability to send
data frames is determined by the 802.11 specification, not this document).
" BSSID and SSID MUST be provided as auxiliary information
along with the link up notification. Unfortunately this information
does not provide a deterministic indication of whether the IP-layer
configuration MUST be changed upon movement."
Given the limitations of the BSSID and SSID, why the
normative language? DNAv4 implementations will not use this
information.
"If authentication is performed, a link up indication can be
generated upon authentication, and a link down indication can be
generated upon deauthentication."
What if authentication is not performed? How are "link up"
and "link down" determined?
Section 2.4.2
" Ethernet networks commonly consist of LANs joined together by
transparent bridges (usually implemented as switches). Transparent
bridges require the active topology to be loop free. The Spanning
Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where
required, the blocking of ports (i.e., not forwarding)."
I think you need to mention RSTP here as well.
" Most hosts today do not listen to BPDU frames. For these hosts,
connectivity to the a port which is potentially bridged (any Ethernet
port) carries the potential of frame loss if transmissions occur
before any bridges' ForwardDelay timers have expired twice."
"to the a port" - "to the port"
" If no bridge configuration messages are received within the
Bridge_Max_Age interval (default 20s), then it is likely that there
is no visible bridge whose port is enabled for bridging (S8.4.5 of
[IEEE-802.1D]), since at least two BPDU hello messages would have
been lost. Upon this timeout, a link up notification MUST be
generated.
It is not easy for a non-STP host to distinguish between Disabled
bridge ports and non-bridge ports with no IP nodes on them, as
Disabled ports will have no traffic on them, and incur 100% sender
loss.
Upon this Bridge_Max_Age timeout, a link up notification must be
generated. If an earlier link up was generated with the R-flag set,
this new one MUST set the A-flag showing that packets sent within the
prior interval were likely to have traversed the forwarding path
(unless the port is disabled)."
The next section talks about when to enable the delay, but I think you
could be more clear about this here as well. For example, are you
recommending that hosts listen for STP/RSTP messages, or use 802.1AB
in order to decide on the appropriate delay? Delaying for 20 seconds
by default probably isn't a good idea now that RSTP is becoming more
common.
" Due to the protocol's newness and lack of deployment, it is unclear
how this protocol will eventually affect DNA in IPv4 or IPv6
networks."
DNAv4 does not utilize 802.1AB "hints", so this could be clarified.
Section 2.4.4
" Link-Layer indications in Ethernet-like networks are complicated by
additional unadvertised delays due to Spanning Tree calculations.
This may cause re-indication (link up with A-flag) or retraction
(link up with B-flag) of indications previously sent to upper layer
protocols."
What are the A and B flags? Is this an artifact of a previous revision?