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

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Oct 2006 14:55:28 +0300

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

---

From: Greg Daley <[email-masked]>
Date: Mon, 30 Oct 2006 19:59:27 +1100

Hi Jari, 

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

I believe that 802.1w has been rolled into 802.1D, so apart from the
references needing to be merged this is OK.

> >    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
> >    Disabled ports will have no traffic on them, and incur 100% 
> sender>    loss.
> >
> > 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.

I'm actually not sure it did (Did we still have the flags??) How about:

"
Where it is not known that forwarding operations are available, a
host SHOULD assume that RSTP or STP is being performed. Hosts MAY
listen to STP/RSTP and 802.1AB messages to gain further information
about the timing of full connectivity on the link, for example, to
override an existing indication.

Notably, though, it is not easy for a host to distinguish between
Disabled bridge ports and non-bridge ports with no active transmitters on
them, as Disabled ports will have no traffic on them, and incur 100%
sender loss.

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, if one has not been already."

I believe this shows that the indications may be sent first when link-layer
connectivity (rather than spanning-tree-connectivity) is available, but 
that hosts need to be wary of sender loss during spanning tree calculation.

Greg
(now employed again).

---

From: Jari Arkko <[email-masked]>
Date: Mon, 30 Oct 2006 11:23:55 +0200

Greg,
> that hosts need to be wary of sender loss during spanning tree calculation.
This would work for me. We would essentially leave
the issue open, but describe the implications.

--Jari