RE: [DNA] Review of draft-ietf-dna-link-information-03.txt

[Alper Yegin <alper.yegin@yegin.org>]

> 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".

The document aims to be useful to both DNAv4 and DNAv6. While it defines the
L2 events and their associated notifications, it does not aim defining how
they shall be used. This is the job of DNA specifications.

I guess there is some residual text that falls beyond this scope. You found
some. We'll clean that up.

> 
> 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.

Oh, we had banned the use of "triggers" in this community a while ago :-)

I've looked at the definition of "Link indications" in your
draft-iab-link-indications-04.txt document. Based on that, an event
notification is a type of indication. Of course, there are other types of
indications as well. For example, a non-event-notification type indication:
L3 can read certain L2 attributes to use them as indications of various
things (e.g., lack of security, lack of bandwidth, etc. etc.)

Do we need to do anything to harmonize the two documents? Shall we state
that "A link-layer event notification is a type of link indication [ref]"?

Btw, your I-D makes statements like "Link Up event should not be sent"... It
is the "event notification" that is sent, not the "event" itself. Event
takes place in the L2.

> 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.

   "Link up" is an event provided by the link-layer that signifies a
   state change associated with the interface becoming capable of
   communicating data packets.  This event is associated with a link-
   layer connection between the node and an attachment point.


> 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.

Irrespective of the "consumer of such event notifications", events do take
place. And they should be marked that way in the L2 (a).

Whether the "event notifications" shall be generated and sent up to the L3
is another story (b). And how they are used is a totally different story
(c).


For (b), I'll scan the document and make sure we don't overstep the scope
and make statements about the event notifications being always sent up or
anything. It's really upto the L3 and the specific consumer if it wants to
hear certain types of notifications (b), and how they want to use it (c).


> 
> 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).

DNAv2 and DNAv6 are the main focus. But.... this document should also be
useful to other protocols, anything that talks about link up and link down
at IETF.



> 
> 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)."

Good idea.

> 
>    "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".

Is there a better term to indicate both connection-oriented and
connectionless link-layers are covered?

> What are "network layer configuration parameters obtained via the
> link-layer attachment process"?  Perhaps an example would help (e.g. PPP
> IPCP)

OK.

> 
> "   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."

We shall remove that text. But I'm not suggesting we remove the "link down"
as described in the document. Even if DNA methods don't use it, link down is
the counter part to link up. It may very well be used by other
specifications. People should have to write a separate document just for
defining link-down.


>    "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.

I think the events MUST take place (i.e., there must be some state variable
in the L2 that indicates the event took place). But I agree it's none of
this I-D's business to state that the event notifications MUST be generated.
Instead, "The link-layer MUST be capable of generating the matching event
notifications. Whether the link-layer delivers a given type of event
notification depends on the local configuration." And this says nothing
about what the network-layer would do if it received any such notifications.

  
>     "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).

Will fix.

> 
> "  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.

BSSID/SSID info is always available to L2, therefore I don't see a problem
in making them available to the L3. Reducing MUST to a SHOULD or MAY does
not really buy us anything, but makes the L2 implementations less
predictable. 

>    "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?

I'll let Nicolas answer that (IEEE 802.11).

> 
> 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?
> 

I'll let Greg answer these (Ethernet).

Alper