[DNA] draft-ietf-dna-link-information-04.txt status

[Jari Arkko <jari.arkko@piuha.net>]

All,

I have reviewed -04 to ensure that it addressed
all the issues. Unfortunately, while it takes into
account the link down decision very well, it does
not address the other issues.

Please see below for a collection of the issues
from my review and from Bernard's review. I
think for most of these there was consensus
to go ahead with the changes and text available.

I initially considered that I would ship the document
forward anyway, by using RFC Editor notes. However,
the number of changes is too big for that to be practical.
Hence, I will wait for a new revision. Please be careful
when you revise drafts in the future that you indeed
have taken everything into account.

My review issues (mail quotes from Alper):
>    Two basic link-layer events are considered potentially useful to DNA
> > >    process: link up and link down.  Both of these events are
> > >    deterministic, and their notifications are provided to IP-layer after
> > >    the events successfully conclude.
>   
> > 
> > I wonder how deterministic these events are in a wireless
> > network.
>   
>
> I think it is best if we hadn't used that term. I'd rewrite:
>
> Two basic link-layer events are considered potentially useful to DNA
> process: link up and link down.  Associated notifications can be
> provided to the IP-layer after the events conclude successfully.
Not in -04

>    A GPRS MT that wants to establish IP-level connections MUST first
> > >    perform a GPRS attach to the SGSN.  This MUST be followed by a
>   
> > 
> > This reads like normative language for the implementation of
> > GPRS L2 operations. I would suggest that such language be
> > left to the SDOs in question. (May apply to other parts of
> > the document, too. Go over the MUSTs and SHOULDs and check
> > that they apply only to the up/down indications, not the
> > rest of the L2 operation.)
>   
>
> I'll take care of them all.
>   
Not in -04.

>  A GPRS MT that wants to establish IP-level connections MUST first
> > >    perform a GPRS attach to the SGSN.  This MUST be followed by a
> > >    request to the GPRS network to settle the necessary soft state
> > >    mechanism (GPRS tunneling protocol) between its serving SGSN and the
> > >    GGSN.  The soft state maintained between the MT, the SGSN and the
> > >    GGSN is called a PDP Context.  It is used for guaranteeing a
> > >    negotiated quality of service for the IP flows exchanged between the
> > >    GPRS MT and an external Packet Data Network such as Internet.
>   
> > 
> > Hmm... there's more to a PDP context than QoS state. I would simply
> > replace the entire text above with:
> > 
> > "A GPRS MT that wants to establish IP connectivity establishes
> > first a connection to the GPRS network and one or more PDP
> > Context associations between the MT and the GGSN."
>   
>
> Sounds reasonable to me. Unless Eric, the author of that text, has any
> comments, I'd go with your suggestion.
>   
Not in -04.

> nts, I'd go with your suggestion.
>
>
>   
>> > 
>>     
>>> > >    An MT has the possibility to establish a secondary PDP Context while
>>> > >    re-using the IP configuration acquired from a previously established
>>> > >    and active PDP Context.  Establishment of a secondary PDP Context
>>> > >    does not provide additional information to IP-layer.  Such a second
>>> > >    PDP Context would basically have a different QoS profile so that a
>>> > >    different type of application can be served.  In that case,
>>> > >    activation of the secondary PDP Context MUST NOT generate another
>>> > >    link up event notification.  However, a secondary PDP Context
>>> > >    establishment that triggers a new IP configuration is to be treated
>>> > >    from the IP layer as indicated above.
>>>       
>> > 
>> > Rewrite as
>> > 
>> >  "An MT has the possibility to establish a secondary PDP Context while
>> >    re-using the IP configuration acquired from a previously established
>> >    and active PDP Context.  Such a secondary PDP Context
>> >    does not provide additional information to IP-layer and only
>> >    allows another QoS profile to be used.  The activiation of a such
>> >    secondary PDP Context MUST NOT generate another
>> >    link up event notification.  However, other additional PDP Context
>> >    activiations are to be treated as indicated earlier."
>>     
>
> My response is same as the previous one.
>   
Not in -04.

> In a WiFi network that supports Robust Secure Network (RSN
> > >    [IEEE-802.11i]), successful completion of 4-way handshake between the
> > >    STA and AP commences the availability of IP service.
>   
> > 
> > Presumably mere support is not the key factor here -- the question
> > is whether the RSN operation has been turned on or not; my RSN-capable
> > network works fine even without 4-way handshake.
>   
>
> I'd rewrite this as:
>
> In a WiFi network that uses Robust Secure Network (RSN
> [IEEE-802.11i]), successful completion of 4-way handshake between the
> STA and AP commences the availability of IP service.
>   

Not in -04.
> 4.  Security Considerations
I thought we had converged on text, but there are
no changes in -04.

And from Bernard's mail:
> 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)."
Not in -04
>
>   "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".
Not in -04. Would recommend striking the first sentence,
and then changing the second one to begin as "Additional
information can be conveyed in addition to the event,
>
> What are "network layer configuration parameters obtained via the
> link-layer attachment process"?  Perhaps an example would help (e.g. PPP
> IPCP)
Not in -04.
>    "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.
Not in -04, but the text does not claim that this is always
done. I'm letting this pass.
>
> 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).
Not in -04.
>
> "  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.
Not in -04. MAY would be appropriate.
>
> 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.
Not in -04. Suggest replacing the last sentence by "This is achieved
through the Spanning Tree Protocol (STP) or the Rapid Spanning
Tree Protocol (RSTP). These protocols exchange Bridge Prototocol
Data Units (BPDUs) [IEEE-802.1D, IEEE802.1W], and leads to, ..."
>
> "   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"
Not in -04
> "   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.
There was a long discussion about this in early July.
Please incorporate the conclusions. This is the only
item where its unclear to me if the discussion between
Bernard and Greg converged.
> "  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.
Not in -04. Greg had a text proposal for this on July 1st.

--Jari