Subject: [DNA] Preliminary Minutes for IETF62 (please check)

From: Greg Daley <[email-masked]>
Date: Wed, 06 Apr 2005 00:28:12 +1000

Here are the preliminary minutes from IETF 62.

Thanks to those who took notes.

Attendees: 
There are some paraphrases and some unknown speakers.
Please check that what you said is accurate.

The minutes have to be submitted by friday, with 
presentation slides.  If you've not sent in your 
slides please do so.

Greg

Monday Minutes taken by John Loughney and Christian Vogt

============================================================
DNA Working Group Meeting
March 7, 2005, 15:30pm to 17:30pm
IETF 62, Minneapolis
============================================================

CHAIRS: Greg Daley <[email-masked]>
                 Pekka Nikander <[email-masked]>

------------------------------------------------------------
Agenda
------------------------------------------------------------

1. Introduction, Status Update
   Chairs

2. L2 Event Notifications
   draft-ietf-dna-link-information-01
   Alper Yegin

3. Media Independent Handover Services and Interoperability
   Ajay Rajkumar

4. DNA with unmodified routers: Prefix List based approach
   JinHyeock Choi

5. BCP For Hosts
   Sathya Narayanan

6. BCP For Routers
   Sathya Narayanan

7. DNA Design Team Update
   draft-dnadt-dna-discussion-00
   Brett Pentland

8. Conclusion
   Greg Daley, Pekka Nikander

-------------------------------

- 10 min wg status and summary

  overview of the agenda
  overview of WG status
  3 items are late
  Goals draft in RFC editor's queue
  Send-CGA has just passed AUTH-48, SEND-ndopt is currently in AUTH-48.

----------------------------------
 - 20 min link information draft
	Alper Yegin
        draft-ietf-dna-link-information-01.txt
----------------------------------

  New version of ietf-dna-link-information-01.

  New text with respect to 802.11 ad-hoc mode.

  New text on 802.3, Greg would like someone to review.

  Comments from John Laughey will lead to clarifications affecting the
  GSM, GPRS, and UMTS parts of the document.

John Loughney:
          Terminology is not so good.  I volunteer for enhancing this.

John Loughney:
          Notifications can be spoofed; this might lead to DoS attacks.
          Volunteer for text on this, too.

  Reviews from Pekka Savola & Bernard Aboba will be sent to the draft.

- 20 min 802.21 status and liaison
  ------------------------------------------------------------
  Media Independent Handover Services and Interoperability
   Ajay Rajkumar 802.21 Chair
  ------------------------------------------------------------

  Media Independent Handover:

  IEEE 802.21 considers handovers between the following technologies
  - between 802.xx and 802.yy
  - between 802.xx and Cellular (3GPP, 3GPP2)
  - between 802.11 ESS
  where x,y = 3, 11, 15, 16.

  Won't specify the mobility protocol used.

  All scenarios but the last are handovers between different 
  technologies.  In all scenarios including the last, the question of
  whether a node has changed IP attachment when it changes its AP is
  a critical one.

  Session continuity is important, so that there is service continuity
  at the application layer.  
  
  Session continuity has three components
  - adaptation to new link at layer two
  - address continuity at layer 3
  - service continuity at application layer

  Lots of info that is required to move from interface to interface and
  maintain session continuity. A basic list was shown.

  active work items:
  - MIH model
  - event-trigger service model
  - information service

  - Should MIH a layer, should an API be defined, should the transport
                 mechanism be defined?
  - How should the APIs to upper and lower layers be defined?
  - Should the transports be defined for remote, local triggers?

  define these in a RAN & in the MN

  MIH model

  Modelling mobile terminals is easy:  Assume PHY, MAC, LLC
  in every mobile terminal except in cellular ones.  But within
  the network, things are more complicated, because a certain layer
  is usually implemented in different entities.

  signaling diagram for the MIH model is shown. See slide.

  signaling diagram for cellular side is a bit different than for the 
802.xx
  version

Keith Moore:
          (paraphrase) objects to the statement "no overlap/no 
switching"
          is possible, thinks its because 802.21 has scoped it outside
          of the presentation.

  Example: MN has 802.11 and cellular interface.  When 802.11 interface
  recognizes fading signal, it signals this information to the MIH 
layer.
  MIH layer looks for alternative interfaces and initiates scanning at 
those.

Alper Yegin:
          asked about the cellular diagram - is it between 2 IP nodes? 
Ajay Rajkumar:
          this is open, not specified.  It could be over IP.

Alper Yegin:
          What are the endpoints for MIH signaling?  Can such 
          signaling be over the air?
Ajay Rajkumar:
          Yes, it could.

Alper Yegin:
          Is IEEE 802.21 developing a special MIH signaling protocol?
Ajay Rajkumar:
          This has been discussed.

Alper Yegin:
          could have some signaling between different networks.
Alper Yegin:
          resembles 'smart networks' like cellular
Ajay Rajkumar:
          that is one scenario, but MN might have the policy

Pekka Nikander:
          What will be carried within the MIH signaling?
Ajay Rajkumar:
          I can give examples, no slides, though.

Pekka Nikander:
          I would prefer to not specify the transport. 
          The reason is that L2 information must provided early
          to/by MIH.  But you have to exchange 15-20 messages
          for L2 attachment with 802.11 or 802.11i.  This, in turn,
          prohibits using IP as a transport in some cases. 
          So, it needs to be carefully considered which
          transport to use.

Ajay Rajkumar: <missed?>

Pekka Nikander:
          It seems that you require all interfaces of a MN to
          belong to the same operator.  This business model may
          not be feasible in all situations.

Someone:
          CS cellular or PS?
Ajay Rajkumar:
          (paraphrase) only PS, no CS.  

Gabriel Montenegro:
          How much information do you want to carry in the MIH
          protocol?  Too much information could be an issue
          with certain link layers.. E.g., the maximum payload 
          that can be carried in IEEE 802.15.4 frames is 102 bytes.
Ajay Rajkumar:
          IEEE 802.15 is not currently directly addressed.  The
          group is chartered for it, so this may be done at a
          later point.

Stefano Faccin:
          (answering to Gabriel) The information carried in the
          transport is modular.  Different link layers use different
          modules, so the information that would be exchanged
          over 802.15.4 would be such that it fits the maximum
          frame size.  Things can also be sent in multiple
          messages/round trips.

Event-trigger service model
- Local triggers
- Peer-to-peer remote triggers

Local triggers
- link up
- link down

Should be generic enough to function over different access 
technologies. 

Other triggers are specific to some bearers.  How to limit the
amount of possible triggers?

Peer-to-peer remote triggers
- authentication done
Several modes of transport; granularity issues being discussed

Alper Yegin:
          What kind of triggers are being defined?
Ajay Rajkumar:
          link up, link down, pre-authentication, post-authentication. 
still 
          being discussed. large number is being discussed.

Information Services
- Security mechanisms
- location
- cost of link

Call for proposal issued on September 28, 2004.
Initial draft text due in May 2005.

Stefano Faccin:
          IEEE has not the power to define a L3 transport.
          This needs to be done in the IETF.

Someone 3:
          IAB l2 draft question? will it be handled in DNA?

Pekka Nikander:
          It is an IAB draft, will discuss with Bernard

S3:
          Thinks that the solution for the MIH signaling should be done
          in the IETF

Pekka Nikander:
          I think we agree that IEEE and IETF need to closer co-operate
          with respect to 802.21.

Alper Yegin:
          802.21 folks may want to take a look at the CARD protocol.
          This protocol can also carry information to mobile terminals
          about potential new attachment points.

S3: yes, it will be considered.

-----------------------------------------
  - 10 min DNAv6 with unmodified routers: Prefix List Approach
                 JinHyeock Choi
                 draft-jinchoi-dna-cpl-01.txt
-----------------------------------------
JinHyeock Choi:
          The DNA WG is working on efficient mechanisms for L3-handover
          detection that may also be applicable to link changes
          between DNA links and non-DNA links.  E.g., look at
          the Complete Prefix List proposal:

  discussion of goals

  basic idea: a host collects all prefix on a link & makes a list. When
  it moves to a new link, it creates a new list.  If the lists are 
  disjoint, then its on a new link. Only RA is needed for movement 
detection.

someone 4: 
ans: 
          there is a kind of hint, then you need a trigger to start DNA 
process.

  greg explains mechanism better.

Keith Moore:
          (paraphrased) thinks the mechanism is broken, if you see some
          of the same set of prefixes on multiple links, then you have
          different links.  You actually can have the same prefix
          advertised on two links.  Links can be bridged.

JinHyeock Choi:
          If two links are bridged, then we consider it one L3 link--
even 
          if this L3 link consists of two L2 links.  (For a definition
          of L2 links and L3 links, see DNA documents and mailing-list
          discussions.)

Keith Moore:
          A prefix may move from one link to another.  This is an 
example 
          (though a rare one) of where the prefix is not necessarily 
tied
          to one link.
Keith Moore:
          Its hazardous that if you see one of the same
          prefixes, then you think two links are the same. 
Keith Moore:
          (paraphrased) some discussion on this, thinks you need to have
          some explicit mechanism to do effectively

Samita Chakrabati:
          We have an implementation of this on the wired network.

Keith Moore:
          thinks this is not reasonable assumption

Pekka Nikander:
          draft should cover Keith's scenario
Keith Moore:
          thinks it is reasonable that the group looks into the
          problem, but not that the problem is solved

WG document?  We want to facilitate its adoption to existing Mobile 
IPv6 code.

Kent Leung:  (paraphrased): didn't read the draft. 
                 What's different from Mobile IPv6 movement detection?
JinHyeock Choi:
          Mobile IPv6 uses three RA's separated by one second to check
          whether an old router is still available.  This takes
          three seconds.  CPL is much faster.

someone 4:
          How long do you need to watch?

JinHyeock Choi:
	  look for 2 RA's on a link

Pekka Nikander:
          How may people are willing to read the document and make
          comments before we recommend the document to the IESG?
          -- 10 or some more.

==> Accepted as WG doc.

-----------------------------------------------
- 20 min DNA hosts bcp draft, with discussion
                 Sathya Narayanan
                 draft-narayanan-dna-hosts-bcp-00.txt
-----------------------------------------------

   issues presented
   
Question (from author):
          The draft makes the assumption that a mobile node,
          when it returns to a previous link within the DAD complete
          time, it may claim the previous IP address by sending a NA.
          Is this alright?  (Discussion delegated to the mailing list.)

Pekka Nikander:
          We are chartered to produce a document that describes 
          what you can do with the current protocols.  In Washington,
          we decided that we would do two documents -- what you can do
          as a host, and what you can do as a router. 

          The question is whether this draft can be used as a 
          starting point for a WG document ?

          How many people would be willing to review the document?  
          --  5 people.
 ==> Enough, but we will need all of these five.
                 (Adopted)

------------------------------------------------
- 20 min DNA routers bcp draft, with discussion
                 Sathya Narayanan
                 draft-narayanan-dna-routers-bcp-00.txt
------------------------------------------------

   issues presented.

Pekka Nikander:
          we are chartered to create a bcp on what to do with
          existing protocols.
          How many are interested in on working on this? about 4 hands,
          so we will work on this.

- 5 min dt update
                Brett Pentland
                draft-dnadt-dna-discussion-00.txt

The design team consists of JinHyeock Choi, Tero Kauppinen, James Kempf,
                Sathya Narayanan, Erik Nordmark, and Brett Pentland.
   
Now its time to think whether there is something that we forgot and that
                needs to be put into the design draft.  

Comment from the audience:
          I think that the assumptions that routers on the
          same link can hear each other is valid.

Brett Pentland:
          That's probably one thing that needs to be further discussed.

Two basic problems

- checking for a link change
- getting the RA fast
First can be achieved by means of a link ID that is put into RA's.
Second could be Fast Router Discovery.

Design team has produced a discusssion document that talks about
the advantages and disadvantages of different approaches.  And we
still need more discussion on everthing.

Someone:
          doesn't think that routers on a link can hear each other is
          not a good assumption.
Someone: 
          question if one solution is reasonable.

ans:
          design team said that this is a possibility, but just a 
suggestion.

JinHyeock Choi: 
          clarify the concept link in document.

Question to the audience:
          Where to go?  

Pekka Nikander: 
          Defer all technical questions to Thursday.  If you have a 
          non-technical questions, go ahead.

------------------------------------------------------------
8. Conclusion
   Chairs
------------------------------------------------------------

Thursday's session will focus on draft-dnadt-dna-discussion-00.  Folks 
are hence encouraged to read the document and discuss it with design 
team members.

The design team has identified a large number of options, and the goal 
is to eliminate some of these options.  It would be good if you read 
the design-team document critically and make comments, so that we can 
eliminate some of the current options.

============================================================
DNA Working Group Meeting
March 7, 2005, 15:30pm to 17:30pm
IETF 62, Minneapolis
============================================================

CHAIRS: Greg Daley <[email-masked]>
                 Pekka Nikander <[email-masked]>

Minute Takers: Pekka Niknder (??)

Topic

DNA discussion 05-03-10
Presentation by Bret Pettland
Clarifying questions:
X:
	  Are you assuming every router can hear 
	  Shared media like Ethernet
          There are other cases, such as access routers connected
          through ppp or similar to an access point.

JinHyeock Choi:
	  We are assuming any two access routers in the same link can 
hear
          each other
X:
	  This link definition is different from what I know
Brett: 
	  Equivalent to Broadcast domains.  Multicast should be received
          by all nodes including routers.
X: 
	  There is this assumption?
Brett Pentland:
	  Yes
Erik Nordmark:
	  Assumption is that if somebody sends a packet to the all hosts
          multicast address then all nodes in the link will receive it.
          If you think of IPv4 you would call it subnet.  In IPv6 you
          call it link.  If for somereason people do link partition.
Brett Pentland:
          definition in 2461
X:
	  The access routers connected to the same access point switch 
          point-to-point connection.  These form a subnet.  But the
          access routers don't hear each other.

Erik Nordmark:
	  Then you have two links that happen to share the same access 
points.
          Must be differentiated by the link layer or otherwise it 
doesn't 
          work. You articifically partition it. There are choices when 
you
          want to have two separate link but you have to carry it out 
with
          VLAN tags or SSID or whatever you want it to be.

 Weeding out discussion

X:
          basestation includes a beacon.  Isn't it sufficient?
Brett Pentland:
          If it is viable, maybe?
JinHyeock Choi: 
	  Link identifier is not SSID.
Greg Daley:
	  Beacon's don't have enough information to identify links
	  Potential security holes in Explicit link ID? Someone could
          explicitly block.
Brett Pentland:
	  A rogue node could come along and change the link ID.
Greg Daley:
	  Yes.
Brett Pentland:
	  Vulnerabilities in all if you are not using SEND. Must be 
considered.
Erik Nordmark:
	  These has been discussed in the design team extensively but 
not
          written down, may make it hard for outsiders to understand 
better.
Greg Daley:
	  Implemented two of the ideas: probabilistic and hash ordered 
RA.
          There is some experience within the working group
Vijay Devarapalli:
	  Nice to have implementation experience.  Get feedback from 
MIPv6
          working group.
Brett Pentland:
	  Get written down.
Erik Nordmark:
	  Get feedback from Ipv6 working group. Understand the 
combinations
          hard? 
Vijay Devarapalli:
	  12 combinations is too many to give feedback.
James Kempf:
	  Make JinHyeock's draft (fast ra discovery) WG informational.
          Proposal to 802.21, we can't really do it in the IETF.
          Lots of issues with different link layers. Reduce the number 
          of proposals at the WG.
Suresh Krishnan:
	  Missing?  
Brett Pentland:
	  Collect the set of prefixes?
Erik Nordmark:
	  You need to have a link detection mechanism and a fast 
          advertisement things
Suresh Krishnan:
	  Some are not really combinaritorical Only 8 combinations, 
          leave fast RA out.
Sathya Narayanan:
	  Landmark is an option.  Do you want.  Only 6 independent 
          combinations
	  Whether you add something on RA on RS.  Orthogonal.
          Benefits from both RA and RS side.  If you do that you 
          are down to three.
Suresh Krishnan:
	  Not that many combinations.  We can decide.
Greg Daley:
	  Helpful if I posted code?
Charlie Chef, Motorola:
	  Tremendous disconnection between 802.21 and DNA.  Very marchy
          handcap here.  We assume that there is very little information
          here.  In 802.21 looking for techical solutions, still all
          individual prosals.  20 some proposed. Not all of them will
          become supported.  Way beyond what we assume here.  If we
          assume even a small fraction of those would tremendously 
simplify.
          Coordination. More informed assumptions
Greg (chairing):
	  Good comment.  .21 will simplify things thing tremendously,
          if you have got .21 interfaces on the network/host side.
          Not every device or network will have .21 interfaces.  
          We want to follow it closesly,  feed requirements to .21. 
          Very much interested in collaborating.
Charlie Perkins:
	  Been involved.  Only value if being used.  User for .21 is 
IETF.  
Greg Daley:
	  At this time it is important what we are actually using.  
Other
          groups have other requirements.  If we had triggers available,
          mechanisms for identifying links.  Will revisit this, 
separate 
          document that follows that.
Charlie Perkins:
	  Put together here a wish list.  
Greg Daley:
	  Be careful here. (don't want to tell other SDOs things we 
don't want)
Erik Nordmark: 
	  Will .21 carry layer 3 information
Greg Daley: 
 	  
James Kempf:
	  Way that .21 works today.  No connection between L2 and L3. 
          Maybe some time when .21 is completed it may change.  
          ESS.  .21 is not chartered for intra-ESS handovers.
John Loughney:
	  DT document rough going.  Move things that should be remove
          to an annex.  Provide main body additional information,
          maybe actual code, experiments.  Would be good to see.
Greg Daley:
	  My experiments not done yet.
	  Minor variations to be.  Nail down if there are any protocol 
issues.
          If we need to specify behavour changes.
Greg (next steps):
	  New version of the design team document.  Additional 
information. 
          Next few weeks. Read it again.  Might be shorter to read next 
time.
          Good idea: 10 hands.
	  Not sufficient?
Erik Nordmark:
	  More information about the proposals that don't have indivudal
          drafts.  Make very short drafts of the right side.
          Example that could be put into the design team document.
Vijay Devarapalli:
	  More detailed specs of each one of the ones on plate.  Weed 
out 
          if we don't get them.
	  Plans to experiment some of these.
Greg Daley:
	  Would be nice to know soon. Good to have as individual 
submissions.
Vijay Devarapalli:
	  Detailed enough?
Greg Daley:
	  Promised to implement afterwards
Suresh Krishnan:
	  IPR considerations needed.
Greg Daley:
	  Must be careful. (BCP 79 referencing)
Erik Nordmark:
	  Rules are there for arhived stuff like RFCs. 
Greg Daley:
	  Could have a note with an RFC editor note.
Brett Pentland:
	  DT document designes basic concepts.  More detail needed.
Erik Nordmark:
	  Maybe the design team could settle with 2 ways, one ipr one
          without.  A possibility.
Sathya Narayanan:
	  Some consensus on one and a little bit of controversy.
Erik Nordmark:
	  That doesn't stop the WG from saying that we don't like.
James Kempf:
	  Do two documents.  Implement.  Measure.  Have a comparison. 
JinHyeock Choi:
	  Do something with IPR if clear technical advance.
Greg (personal):
	  I will supply test results wrt. main perfomance, delay,
          packet loss levels.  Provide at the mailing list. 
Greg Daley:
	  Clear way ahead with DT, clear enough to implement. 
          Will remain individual submissions.
	  Sense of room:
	  Useful to record the DT considerations: 10 hands, no: no hands
	  DNA solutions framework:
	  Not to loose the MLD and DAD stuff
James Kempf:
	  Probably be BCP?
Erik Nordmark:
	  Changes protocol behaviour even though.
Greg Daley:
	  Could go to the exiting mile stone. Discuss on the list.
JinHyeock Choi:
	  Also applies to solutions?
Greg Daley:
	  Solutions will probably refer to the BCPs.
Erik Nordmark:
	  Willing to update
Greg Daley:
	  Some to move to host BCP?
Erik Nordmark:
	  Host BCP stuff that someone wants to implement in one place.
          Some DNA and other things there.
Greg Daley:
	  Update the framework.  Text to move to BCP, ask on the
          mailing list.  Don't want to loose the information.

	  Design team considerations: Brett and Sathya will collect.
	  
EoM.