WG.Detecting Network Attachment WG (dna)


Tuesday, March 2 at 1300-1400
=============================


CHAIRS: Greg Daley (greg.daley@eng.monash.edu.au)
        Pekka Nikander 
(pekka.nikander@nomadiclab.com)



Notes taken by Carl Williams (carlw@mcsr-labs.org)


Pekka and Greg:


DNA meeting is 1st meeting as an official working group.


There is a goals draft and it is recommended that you go through that 
draft. There will be 2 presentations on link layer issues : how to detect 
layer 3 configuration and layer 3 things.

Only clarifying questions during the presentations.

What to do with BCP draft status will be discussed at the DNA working 
group meeting.

Working group status on the following items:

DNA Goals. Link hints catalog which Alper Yegin is in charge of. Link 
layer catalog is what existing in current wireless technologies and what is 
already available in link layer technologies : both wireless and 
wirelan.

BCP editor is Brett Pentland.

DAD optimization has moved to IPv6 working group. Have that working group 
look at those ideas. We will track that work to make sure that these ideas 
are getting the right amount of attention. Please contact IPv6 working 
group chairs if you are interested in helping out in this area.

The co-chairs expressed an interest in security area reviews of 
documents produced in DNA as well as cross area review for operation we 
define as well. We are interested in making sure that the procedures we 
make are actually useful.

There is a quality plan producing work in DNA - tools and 
mechanisms.  Ideally what we would like to see is through internal review of 
documents before they are advanced. Information on review will be put on the 
mailing so that feedback can be obtained. 

Issue tracking will be used. Editors will be the first point of contact 
that will need to respond to reviews.  Chairs will also help out here. 
Looking for generating standard track documents in this group. Working 
group documents will all have issue tracking so that everyone knows what is 
going on.  There are tools out there to help us. 


DNA working group has put in place three processes:


1) input from ADs -  takes place once draft is stable; 
2) input from other working groups and other areas; 
3) once this happens the draft will be released to initial working group 
last call on the respective document.


Glenn Zorn: With regards to the issue tracking system you plan to use, will 
this be a tool for chairs or an automatic stopper for the draft. Way used in 
EAP and AAA working groups - has been less than useful because issues are 
added to the list without any rational or appropriate critic. If someone 
says there is a problem than it is a problem. Glenn says that the chairs 
should decide if indeed the submitted issue is a problem.

Pekka: Issue tracker is mostly a tool for the editors but also chairs can 
use it. The issue tracking system has three different purposes: First, keep 
track of issues so don't get dropped. Second, if have 
controversial issues that we eventually have a consensus on those; and 
third: if we get back to some issue that we resolved already we must have 
some real new input on issue before we resolve it again. We don't want to 
get into loop of keep going back. That doesn't mean that we can't go back to 
issues that we resolved. We don't need to resolve it again - we just need a 
good reason for doing so - for example, new experience, etc.

Greg: Some ways issue tracker been used successfully. For example, Jari's 
usage with the MIPv6 specification - there is an audit trail. Finished this 
issue and people agreed to this on the mailing list. Issue was tracked from 
start to finish.

Pekka: Chairs need to work with editors and follow the mailing list. Get the 
issues resolved fairly soon - so issues don't stay there forever.

Greg: Moving on to the agenda. There are a couple candidate drafts to 
consider for working group adoption: Hints and goals. Good work gone into 
them. These are individual submissions. Review of these documents will be 
done on mailing list. 



JinHyeock Choi presented on DNAv6 goals. 


Definition DNAv6 Goals is a charter milestone.


      - presentation of progress and review feedback.
      - existing work is in the draft:  
draft-jinchoi-dna-goals-00.txt


JinHyeock went over 12 goals that are outlined in his draft.


JinHyeock then went over problems/issues that were identified:


- Should DNA solution take into consideration the problems caused by 
renumbering. JinHyeock says: No.  We don't think that renumbering has 
anything to do with link change.  


Comments/issues:


Pekka: Renumber was raised on mailing list. Charter doesn't say 
anything on renumbering. Pekka stated that he and a few other members 
discussed this issue and concluded that the DNA nodes won't care about 
renumbering. That you will know in advance of renumbering. Our view is that 
it may not be a real problem for DNA but we could be wrong. Does anyone 
feel strongly about renumbering in this work?

Erik Nordmark: What does renumbering mean in this context? New prefixed 
being introduced and old prefixes retired. Is this a problem?

Pekka: It may be a problem if you do it quickly. 

JinHyeock: Little connection to network change.

Erik: May be a problem if get a new prefix and you may think you are on a 
new link. May be fooled that you moved but you didn't. I don't think that 
this is harmful; you may have wasted a few packets trying to determine your 
new router for example.

Pekka: If you make an assumption that you are coming back to the same link 
after a very short delay you can rely on the same topology you had before - 
that is one goal. When we go into the solution space there may be a 
solution to suggest things like that. If the link goes through 
renumbering in these kind of scenarios - there may be some problems. 

Erik: As long as you keep the lifetime in cache then you are fine. You 
don't do anything different if you stayed on the link. 

Bechet Sarikaya: These goals look like requirements. Why are they called 
goals?

Pekka: First for practical reasons. Bad reputation of the "R" word in IETF 
(requirements). Second, if we look at these goals and for example, we want to 
do something fast and something precise, than these may be 
conflicting goals. If we make these requirements, we may not be able to 
fulfill that. So these are the goals that we should work towards. There 
will be some compromise in the process.

Pekka: Please review goals draft and send emails with comments to the 
mailing list. Now we will spend time on issues that interface with layer 2. 
We definitely want to have comments/feedback on these drafts as well. 



L2 hints draft                  Alper Yegin


       -  Definition of Existing L2 Hints applicable for DNA processes is a 
charter milestone.
       -  Presentation of progress.
         - Existing work is in the draft: 
draft-yegin-dna-l2-hints-01.txt


Presentation is recap of what Alper presented at last IETF. Just provide 
recap. One of the main objectives of this DNA working group is how 
identify how link layer can help DNA algorithms. The purpose of this draft is 
to cataloguing well-known link layer technologies and their 
capabilities - nothing fancy - not purposing how link layers should be 
verified, etc. Draft defined event notifications from link layer as 
triggers - and they are triggers to the DNA algorithms. DNA would be a 
consumer of such triggers. There are two types of triggers discussed in the 
draft: link up and link down. For example, in cdma2000 PPP 
establishment would be a link up trigger. 

Hesham Soliman: Might need to distinguish between linkup first time and 
link change during handover. Implementation: don't get same trigger - in 
WLAN for example.

Alper: Look at from perspective as two primitive triggers.

Pekka: Bring up this discussion after all presentations.

Continue on with presentation: Alper states that the draft also defines a 
hint. A hint from a DNA perspective is auxiliary data delivered in 
association with a trigger. It has been identified that receiving 
explicit triggers and hints from the link-layer would expedite the 
detection process. For example, the link-layer indicating that the host has 
established a new connection can be used as a trigger to further probe the 
network for a possible configuration change. 

Unlike the technologies used in 3GPP/3GPP2, network layer 
configuration is not provided as part of link-layer establishment in IEEE 
802.11 networks. Aside from not providing the IP address 
configuration, this link-layer does not present a useful hint to be used 
with the network attachment detection process either. This is due to lack of a 
one-to-one mapping between IP subnets and link-layer parameters. 




IEEE 802.21 work on triggers    Dj Johnson


       - Link Layer information where available can provide hints as to 
handover.   IEEE handoff group aims to provide useful information to L2 
peers and upper layer protocols.


       - Discussion of potential interaction or delineation of work 
between DNA or IETF and 802.21.


Reason here:  what this IEEE working is doing and how he feels it is 
relevant to DNA.


The documents relevant to the IEEE 802.21 triggers discussion this 
afternoon can be found at:



http://www.ieee802.org/handoff/march04_m
eeting_docs/Generalized_triggers-02.pdf

http://www.ieee802.org/handoff/march04_m
eeting_docs/802.21_IETF_DNA_r2.pdf

http://www.ieee802.org/handoff/march04_m
eeting_docs/802.21_IETF_Mobopts_r1.pdf


802.21 IEEE group has been approved as a full IEEE WG since February 27.


Some areas that the 802.21 group is looking at: (1) 
Multi-interfaced devices (2) Session maintence across heterogenous media and 
(3) L2 support for L3 DNA and L3 mobility optimizations.

David stated that some of the problems that they intend to address deal 
with issues such as that you don't know what you are to you are 
associated or plugged into a L2 network. Upper layers don't know what is 
going on at L2 and so can't make good handover decisions. There is no 
media independent way for asking for handover related information over a 
link. A conduit is needed.

David presented that some of 802.21 working group priority work is 
related to DNA - put in place useful L2 network detection methods. Also to do 
handover optimization - handover information and transport as well as L2 
triggers. Other things such as Cellular coupling methods are part of the 
problem scope as well.

DNA related work includes CUPE (Controlled/Uncontrolled Port Entity) which 
provides media independent access to information. DNA is the primary 
purpose of that information. 



David will talk about Triggers in MOBOPTS.


David stated that high order bit of his coming to IETF is to advance 
coordination of  activity - get feedback on what is useful : if there are 
better things we can do and things are meeting your needs.


Feedback?


Pekka:  questions.

David will be available till Friday.

Pete McCANN: question on commonality of information base IEEE, 3gpp, 3gpp2 - 
what kinds of things do you see common across these different links.; 

David: network types and vendor ids can be clearly generically defined. 
Things that are not clearly generic we will mark as such.

Hesham: Useful for this working group to classify link layers at some 
higher layer and what can be done and not be done as well as determine what 
info can come from these different types of link layers.

David: This is concern of 802 in terms of what l2 is providing. Common 
framework and putting .21 at the top of that hierarchy is something we want 
to work out. Take further step above this : look all link layers in 
general.

Greg: Are you pretty sure there will be different mechanisms on 
point-to-point links versus multi-access links. 

Hesham: From DNA perspective point to point may be independent if you use 
PPP or not. 

Pekka: If you have further questions please send to mailing list.

Greg: Quick conversation on "Best Common Practice" (BCP) - not a 
document yet but want to make sure we are in agreement in the 
direction we will go with the BCP. The viewpoint we come to is to what can be 
done with current RFCs and RFCs that are in edit queue. No new protocol 
mechanisms for BCP. We don't have a huge amount of information in the 
operation area but have info from research. If you want to be involved in 
BCP, please contact the DNA co-chairs. 



DNA website has slides for this IETF meeting. 


Pekka: one possible experimental approach in final presentation.  We won't 
consider solutions until make good progress on BCP.   This is just give 
some ideas what these discussions will entail.


Proactive Approach for DNA      Eunsoo Shim


         - This presentation provides a preliminary look at one of the 
proposed solutions for DNA.  In this solution the Candidate Access Router 
Discovery protocol provides adjacent Access Point and Access Router 
information for use in determining configuration change on link-up.


        - Description of this approach is provided in the individual 
submission:   draft-shim-dna-proactive-00.txt


A MN needs two phases of processes to be able to support IP 
communication: link establishment between the MN and an AP and IP-level 
connectivity establishment. Eunsoo described two possible approaches for 
optimization:  (1) Reactive approach - Aquire all the necessary info after 
the link change has occurred (probable after the l2 Trigger) - DNA 
process is in time-critical path.  (2) Acquire (some of) the necessary info 
Before the link change and use it for DNA process after the link change.


Eunsoo described three possible ways to do this:


1. Embed L2 info into L2
2. Memorize information about the old links (locally stored and Managed by 
the MN)
3. Information provisioning by the network
Here a possible tool is CARD protocol.  It was submitted to IESG as an 
experimental RFC recently. Need more info for use by DNA : for example, 
defining the information types and their formats.



Pekka:  This is the kind of idea that we would like to review later.


Rajeev Koodli: Approach is not specific to CARD


Pekka:  Yes, we know you can use FMIPv6 and things like that as well.


David:  Something that we anticipated in .21 and it seemed that doing this 
effectively we have to do interactions between L2 and L3.



Thomas Narten:  Focus scope of this group to be is when attach to link - 
 - determine if your IP configuration parameters changed and configure 
quickly.  The scope of the working group is not specifically about 
movement detection and try to make movement faster.  Anticipating 
movement is pretty far ahead of the scope where we are focused right now.


Pekka:  That is right.  Thinking about these possible 
solutions/enhancements should be at the current IPv6 protocol (i.e, RA), 
etc., and to see what we can do there.  Either way I think if we might know 
what might be in the future we can consider dangers that are related  -  we 
don't follow those problems yet - on document level we don't follow - but on 
protocol level we can consider dangers.


Thomas: we don't want work done  else where creeping in here - CARD and 
FMIPv6 are examples.


Pekka:  Agree.


Joe (?):  What happens when you don't know your access link is virtual


Not just talking about delay but also topological constraints such as ND and 
NS need not apply if your access link is virtual.  How much are you 
talking about the architecture here that your assumption is that your are 
talking to a virtual device and what happens when that isn't true.


Don't know if you are tunneled or not.


Pekka:  Text should be added to BCP.  If you can contribute some text to the 
BCP. 


Gabriel Montenegro:  technology is available but not widely deployed.  What 
people do today on field - this is what BCP are - but GAB sees SEND in 
listing.


Thomas:  BCP stands for "Best Common Practice".  
It doesn't mean that it is "Best".
It doesn't mean that it is "Current".  
It doesn't mean that it is in "Practice".  
It could even mean "Least Worst Practice".   
What it really means that it is the current landscape of what you can do 
based on what we know today - what is available and what we have 
developed -  this is the thing that we ought to be doing.


Pekka:  Please remember to review drafts and provide feedback on mailing 
list