Subject: [DNA] Dallas meeting minutes.

From: Greg Daley <[email-masked]>
Date: Thu, 20 Apr 2006 23:50:42 -0400

Here are the recently reconstructed meeting minutes.

G'Day everyone, it's greg here, we're going to try to get the projector
working. 

It's always fun being first up.  We'll see if we can get through the
technical difficulties,
but I think we're going to start immediately I think.  So, if you didn't
know, this is
DNA working group, there's nothing on the screen to tell you, so.

And we're just going through some of the documents today.

I think the agenda today is 5 minutes of agenda bashing,
15 minutes of document status, and that's primarily the 
   documents we don't have a lot of work to do on right now.

We've also got 30 minutes for discussion of two documents
which are the Complete Prefix Lists and the DNA hosts document.
which we got some feednack from Thomas Narten About.  also
we've got 50 minutes for assigned for the DNA solutions protocol.

Hopefully we'll have audiovisual cues. byt then...

At the end of the discussion about solution space, we're going
to have a look at future directions, and try to fix the charter milestones.

Does anyone have any questions

<greg offers to buy a drink/sandwich for anyone who can remember the agenda>

<gap in minutes: audio server unplugged>

Sathya Narayanan:  DNA hosts feedback.

Sathya Describes redoing DAD, not redoing DAD on each cell change,
and the tradeoffs:

"Why do you have to do DAD if you're only disconnected for 10sec/30sec"?

Also there's a possibility that the possibility that the collision chance
is very low.

(James Kempf) JAK: Assumption behind not redoing DAD, is that the cost
of DAD is
     too expensive
     and if you're doing optimistic DAD its not expensive any more.
Basically,
     the ability for sending traffic from the address isn't impacted, 
it might
     result in some additional NS, hopefully no NA traffic, so I guess I
don't
     see that as a problem .
 
     The second one, the assumption behind that one is that  Duplicate
Host identifier
     detection is sufficient, and there's been a lot of discussion about
this in
     the IPv6 working group, and I believe that the consensus on that
was that no,
     that's not sufficient.  And I think that RFC2462bis draft no longer
recommends that.
     If anyone else here is more familiar with that.

Vidya Narayanan: James's is optimistic DAD not more expensive or is it
time sensitive?

JAK: It's not more expensive in terms of having to wait to send traffic.

Vidya:  How about in terms of signaling?

JAK:  The signaling is the same amount.  You have to send the NS, that's
true.

Vidya: So I don't know, I tend to agree with thomas here.  At least it
should be
      a SHOULD and not a MUST to run DAD every time.

JAK:  I think a SHOULD is sufficient.

Sathya:  What is in the text right now?

Greg:  Just keeping it interesting. So when you run DAD, you don't
necessarily
      have to send the NS immediately.  If you're keeping your interface
optimistic,
      it doesn't matter. You might just run DAD periodically, and keep
optimistic 
      state, if it's not too expensive for the host.

      So you arrive on a link which you are not  sure whether you're at
a particular
      link or not, and you set your link-layer addresses as optimistic.
 And you do
      your router solicitation, and get back a router advertisement.  That
      Router Advertisement indicates whether you're on the same link or
on a different
      link.

      Now, if you're on a different link, you discard a lot of your old
global prefix
      configuration anyway, and you have to do duplicate address
detection.  If you're
      on the same link, this is the case, right?

      We're back on the same link, we're not sure whether someone's
arrived in the
      period where we disconnected and reconnected, so the question is,
what's the cost
      and what's the benefit?

      Well the cost is that  they've come while we've been absent and
have completed
      Duplicate address Detection, we have completely conflicting
addresses.  So if we
      just leave our interface address, our global interface address as
optimistic, 
       until we've done a full check, then that is not so bad.  And if
we keep on
      moving rapidly, we don't necessarily have to send the NS every
time.  We can just
      leave the interface address in optimistic state until we've
completed the NS probe.

      So that's another option.  And that has slightly lower costs when
there's a lot
      of movement.  If it's not a lot of movement, I think we should
just do it anyway.

Sathya: In terms of recommendation, I guess it means, making it should
instead of must.

Greg: Yeah, and may indicate that you want to use hysteresis there as
well, and keep
      the interface in optimistic state.

Sathya: Sure.

Tatuya Jinmei: Actually, I'm not too familiar with this issue but, I'd
like to be sure
      about the question from james.  Are you talking about the
consensus in RFC2462bis
      About whether we need DAD and whether it depends on the interface
identifier
      based on the IEEE address?

JAK: in rfc2462, I believe there's an assumption that you can run DAD
once on the link-local
      address if you generate it using the IEEE identifier. After that
you can reuse the
      identifier, in your global addresses without actually having to
perform DAD.
      
      And I know there was a lot of discussion in the IPv6 WG about that
and I recall,
      maybe I'm wrong, that there was a consensus that that shouldn't be
done.

Jinmei:  That's true.  And so basically I think we should do DAD
regardless of the details
      of how the host attaches to the network.  But I also tend to agree
with greg that
      if a node wants to avoid the overhead of DAD, so it should perform
optimistic DAD.
      So I don't see any problem with this approach basically.

      I don't know if DNA specific issues exist or not.

Mohan here, so this is pretty complicated I think, why do you have to
complicate the
      situation? it's not clear what we're trying to optimize, so is
this case a common
      case?

JinHyeock:  Allow me to clarify the problem.
     Assume a host becomes an idle mode and then comes back to life
     again.

     It can use all the previous IP configuration, prefix list, or routers,
     but, there may be some other host starts to use the address while
the host
     doesn't defend using its own address.  The problem is: shall we perform
     DAD again or not?

Two people:  We should (I guess).

Sathya: That's what we want to recommend

Greg:  So essentially though, this happens whenever a device disconnects
     momentarily and reconnects to the same LAN. So, at IETF, in the big
plenary,
     everyone's using their wireless LAN and the wireless LAN
connectivity's not
     so good and (this is in past meetings of course, not this meeting),
then you
     come back on and configure an address and there's a small
possibility that
     someone has configured an address in that interval of time.

     It's a very small possibility.  Are we going to do DAD every single
time?
     That happens.  Now you guys know how often that happens with
wireless LANs.
 
     So do we run the full DAD? probably not...

     Do we run optinistic DAD? maybe

     We need to figure out if this is what we recommend.

Christian Vogt:  Just one quick note: with regard to the signaling overhead,
     You not only need the NS for DAD but you also need the MLD report,
right?

     Yes, right, and as you said you can also delay that, as part of oDAD.

     So if you don't do oDAD every time you chnge a link then you also don't
     need to send the MLD report every time.

Vidya:  So there are networks where you may never ever run DAD, because
you know
     that your suffix is unique, believe me there are networks, so we
can say
     should and move on.  I can't understand why it is such a
complicated issue.

Erik Nordmark:  I think Should is the right word here because if you
think carefully
     there are cases where it isn't actually required, right?  It
requires thinking
     carefully.  I don't know to what extent we should go into issues in
the document
     about the probability discussion, because it is very different when
you  decide
     that you've moved to a different link, where you potentially have
duplicates with
     the population on the new link, and you have no idea what that
population is,
     and in the plenary, and you get disconnected for a millisecond, 3
seconds, whatever.

     Even if it's a large population there, it has to do with the
probability of someone
     else arriving in that population and picking an address that's your
duplicate.
     And that probability has something to do with how long you're gone.

Greg:  For any single node, it's O(2^62), right,  so it's N times that,
because
     the address was previously unique. So they had to collide with your
address.

Erik: Yes.

Greg: It's a low probability

Erik: Yes.  I think we still need to go into optimistic, until we've
decided that
     we didn't move, but once we decide that we didn't move, do we
actually need
     to send the NS?  Saying well, someone may have arrived and taken
the same address
     as ours, well yeah, if you were gone for half an hour, it might be
a good idea,
     but, seconds, no, that doesn't make sense to me.

Sathya:  It sounds like the consensus is that we change it to SHOULD.

Erik: But I don't know if we want more text explaining stuff saying, well,
     should do DAD is part of the statement, saying, you have to go into
optimistic
     anyhow, but the question is do you actually send a DAD probe?

     And I think we can say something more infromative than just SHOULD.
 We can say
     well it has to do with the amount of time you've been gone.  If
you've only gone
     a few seconds, you don't have to bother because the probability
mumble mumble
     * he actually said those words *
 
     If you were gone for minutes, hours, yeah it may be a good idea.

Mohan:  Should is OK, I think, but then the level of details, I'm not
sure about that,   
     saying, 10 seconds, 30 seconds, are you going to come up with
consensus on that one?
     is 1 second good, is 20 seconds good? I don't know?

Greg:  So the question is, I mean, it's going to very a lot by
environment. And one
     of the things that we found in existing documents which we're
breaking the rules
     of is that when they said SHOULD, they didn't necessarily explain
all the reasons
     why you'd want to do something.
      
     So maybe we should leave that sort of latitude for other people in
the future.
     I don't know. Maybe we just don't explain it and just put the should.

JinHyeock:  One more thing concerns me is that DAD is outside of DNA
scope, so is
     it OK for us to define such a thing?

Greg: Yes.

JinHyeock:  Maybe Jinmei is not happy about that :)

Greg: We shall invite Jinmei to review it. :)     

Erik:  So I don't necessarily think we have to pick a number, right?
      But I think that saying that it's related to the probability of
someone
      else arriving that makes it different.  That would actually help
people
      figure out what number should I pick..

Sathya:  So I think this is the last issue, from thomas.
      Which is about retaining the current IP configuration.
      What breaks if the host send such packets, if there's 
      no chance of collision.

JAK: Well, what breaks is the application. Again this depends on
      whether you believe that the purpose of DNA is to optimize
      handover and make it quicker, or if in the most likely case
      you're going to be in the same network.

      If you think about voice over IP, right, the difference is 
between these
      two choices. 1,...,2,3  or 1,X,3. 

      So which do you want your phonecall to do, when you have handover.

      The first case is where you are waiting until the address has been
fixed.

      the second is where you're just sending and there are drops in the
middle,
      and there's disruption in the stream.

      Personally, I like the first case.  I'd like to have that.

Erik:  So I was chatting with Jane Hook about this last night.
      I think there may be different cases, based on the scope of the
destination
      address.  So the potential danger is that someone creates state
with an address
      that might be a duplicate, which is similar to the DAD discussion.

      That might happen in TCP, because you send a SYN, right.  I think
there's a
      potential danger, if I'm sending a packet with a source Link-Local
Address,
      to a destination link-local address, it might end up creating TCP
state for
      that link-local connection which I didn't actually intend, because
I don't
      actually know that it's my address yet, because it might be a
duplicate.

      Now this state may affect the true owner of that link-local
address, that was
      there before. So there's a potential issue about sending packets
that have a
      source address which you don't know is unique, when it creates
state which
      will upset somebody else.

      But if before I move, I have a communication with a global
address,  global
      destination, my global source. If I move to another link, i cannot
possibly
      cause a problem for the people on the new link, because it's the
prefix for
      the old link I'm using.  So even though my old address isn't valid
      on the link, my global address is not going to be conflicting with
someone else
      on that link, because htey have different prefixes.  Hence sending
another
      TCP packet to that other global address should have no ill effect
whatsoever.

      Yes, the return packets are not going to come back to me if I
move, but, so 
      that way you can actually say: yes, in the normal case of global
communication,
      nothing can actually break.  

      If you're using link-local addresses to communicate, you should
defer that 
      until you know whether they have a duplicate or not.

JinHyeock: I think we'd better make it clear how a host manages it's IP
configuration
      with respect to the DNA procedure.  I don't think it's wise for a
host to start
      using its configuration without any constraint.

      For example, the DNA design mandates that the host moves to
optimistic state 
      to use TSLLAO, instead of SLLAO.  I think it would be best for the
host to
      just keep the information, but to start using it only after the
DNA process
      is completed.  But I don't know if we should ban such behaviour
altogether.
      Maybe we should define it more clearly.

Greg:  OK.  This conversation's been good, but it reminds me a lot about
a conversation
        we had before DNA was chartered.  I think Bernard Aboba raised
the issue, and
       we had exactly this discussion, and came to somewhat similar
conclusions to Erik.

       There's no neighbour discovery problem if you send packets from
the wrong
       global address, to another global address.  There may be an
application problem.

       And this was not something we were necessarily ging to deal with
at the time.

       We can probably deal with it now, in this document, or another
document,
       if we need to describe whether or not we halt the data heading
out using the
       destination cache, or if we just let the data go out and get
retransmitted.

       That might feed back into what Hannes was talking about some sort
of API with
       indications going up the stack to layer 4 from layer 3. So I
don't know 
       if that's additional work that we want to investgate, or if this
is a critical
       issue for this document now.

       It will be application dependent.

       Even if you do let it (note: transmission during DNA
confirmation) happen.

       It's the difference between induced loss or induced delay, and
there's
       different classes of applications which treat those differently.
 
JAK:   So the current document actually I think the current document
actually says,
       that before DNA you put the addresses in to Optimistic state,
which means,
       and I believe it does say you should wait but I'm not sure,  

       So I guess I don't see  any problem with this.  I think it really
depends on
       if you think you're going to be in the same subnet often or not.
       And I don't know that actually, upper layers need to know about it.

       It seems to me if.... I don't really see that with optimistic DAD
you're
       going to have a problem.  

Mohan: So by application, you mean that packets are arriving on the old
link, which
       can mean that you can send packets with the global address, but
the packets
       are not going to come to the new link, they'll go to the old
link, and that
       can potentially, cause problems if someone has the same address
on the old link.

Greg:  Not so much about that.  It was more about window exhaustion for TCP.
       What happens to the actual application, if data flow drops of
because you're
       seinding packets which could be used as acknowledgements to
continute the TCP
       flkow stream.  You're not going to know they're missing until you
start
       receiving packets, which is at least an additional round-trip. 

       So there are a few problems there.  You might get TCP
retransmission timeouts.

       If you're inducing additional delay because you're queueing the
packets, it
       depends on how much longer the DNA process is taking. and whtehr
that 10-20ms
       are going to affect your jitter buffers for voip.

       so they're the two ends of the spectrrum. Eventually it may be
useful to have
       control over that on a per-stream basis.

       I don't think we have to go anywhere near that in this document.

Sathya: So if I understand the answer to that question, as to what
breaks, the
      answer is: it depends.
       where you are, what you are doing.  So if we take thomas's
answer, that
       if nothing, then no harm done.

       The answer is not nothing, so, I guess it should be a SHOULD.

Greg:  My guess though is nothing breaks in Neighbour Discovery.  That's
my quick
      summary.

Sathya: DOes it affect neighbour discovery? or is the question does it
break in general?
     I'm just reading thomas' question word for word.  and his question
is what breaks?
     Since the answer is not nothing, I'm just suggesting that we should
probably just go
     with the requirement that is there.

Greg: I'm not sure that TCP breaks.  There's a chance of retransmission
timeout.
      TCP has been doing this for a while, and there's some interesting
ways to handle
      packet loss over networks, so particularly over wireless networks.
      So we could bring up a "Somebody Else's Problem" field and let
someone else work
      on it.

Sathya:  So you are saying the answer is nothing.

Greg:  Probably nothing if you send the packets.  There may be
additional induced
     delay (note: due to loss and retransmission).  Low probability of
TCP reset exists.
     I haven't done experiments, so that comes with a caveat.

JinHyeock: Do you even think it's OK to send a neighbour advertisement
with SLLAO?

Greg: No.

JinHyeock: SO I think we could make some distinction.

Sathya: What packets you are sending.

Greg: Yes, whether or not neighbour discovery matters: It does matter.
because
     Neighbour discovery packets can change neighbour discovery
state/neighbour cache state
     on other devices.

     So, there has to be a distinction between ND packets, with global
addresses and
     other packets.  We'll have to check that.

Sathya: yes.

Sathya:  I just added this 5 minutes ago.

     So I'll let james describe.

     It has to do with NetLMM domains, and whether we do eager or lazy
switching.

2225.
JAK:  So the current draft doesn't say much about what the host should
do about 
      a defualt router.

      In the actual case where you have IP links where they are separate
subnets,
      there are a couple of corner cases where this may be useful.
      If the route rgoes down or if you take it down for maintenance, it
might be
      useful  where the mobile node moves from one access point to another.

      But it's more interesting for NETLMM, where each router has a
separate link,
      with separate routers, and there's a separate multicast domain,
broadcast
      domains rather.

      The different routers advertise the same prefix, and that prefix
is managed
      by an anchor point further back in the network. So what we'd like
to do is
      have the router advertisments (Note: did he mean router
solicitations?) update
      the mobility anchor further back in the network, and have the same
prefix
      be advertised.

      The problem on the hosts though is that if it doesn't know it's
moved to a
      separate broadcast domain, and receives an RA from a new router,
it doesn't
      know that the old router isn't reachable any more.  It would be
nice to have
      a way for the host, once it receives back a collection of RAs
after sending an
      RS, and the old default router is not on the list, that rather
than going
      through a long complicated process using NUD and all that, it
basically says,
      I know these are reachable, it starts to use these routers instead
of the
      old one which may not be reachable.

      I was looking at the router preferences RFC today, and it looks
like there are
      (greg suggested I look at this last night) and there might be
something we could
      do with that.  But I thinkwe should put some paragraph in the DNA
document,
      indicating what you should do, but it shouldn't be a MUST, 
because there are some
      cases you wouldn't want to do this.  It's basically an optimization.

      And what I can do is write some text up, and put it on the list,
and if anyone
      has any violent objection to it, we can write discuss it here or
on the list.

Sathya: is this an issue only for netlmm or more general?

      I mean there are ways of fixing this for netlmm

JAK: like what?

Sathya: We had some discussion on this.

JAK:  Yeah, but it was a hack. It was for all the routers to 
     have the same link-local address. And that's not acceptable.

     And it also doesn't work if you have multiple routers on the links.

     In a single link, you don't need to have the same link-local addresses.

Sathya: in a single link, you don't need to have netLMM addresses.
     But between links, you could have the  set of link-local addresses.

     I don't know what the definition of hack is here, but what the router
     advertising the same set of addresses.

JAK: THis is the definition of a hack: A piece of inelegant design which
requires
    unacceptable amount of human intervention to work (in this
particular case).

Greg:  I enjoy hacks, but apart from that, that solution will not work
with CGA,
     unless they share the secret key.
     So as far as I'm concerned, that's enough to block that hack.
     Hacks are alright, but if they stop us doing what we want to do,
that's no good.

     One of the other things that we could consider was that last
meeting, we
     were trying to consider if anyone had any use, in the future or
today for
     non-prefix link identification.

     An identifier not tied to the prefix, but to the link.

     Now this may actually be a case that we need it for.
   
     I'm not sure.

Sathya:  No, the link identification, is not the problem here.
      
Greg: You need to be able to tell the link has changed here to identify
     that the old router isn't available rapidly.

Sathya: No, if the link hasn't changed, but the router interfaces have
changed.

Greg: It has changed in this case.

JAK:  I think what greg's trying to say is that if you don't have link
identifiers
     which are prefixes, you can have a separate link identifier, which
is different
     on every link, and advertise the same set of prefixes across all
the routers.

     THe way it is currently, the link identifier has to be one of the
prefixes.
     Then you'd recognize that the link had changed and and go through
the link change
     procedure and that will involve getting a separate default router.

     Now that again brings up the question what about addresses because
the addresses
     are going to be the same. That would require a change in the
section about addresses
     saying that if the prefixes are the same and you've changed link,
you don't
     really have to chenge prefixes.

Sathya: Yeah, and we are changing the definition of link, 

2832

Mohan: it doesn't work because change of link due to link identifier,
according to DNA
     you have to do all the stuff, whereas what NetLMM wants is just
change the 
     default router but don't do the rest of the stuff.  it may not
exactly match with
     the link identity.

     Just say the link id changes, it ,means differne thtings in DNA and
netlmm

Sathya: We would have to revamp the way link change is handled in DNA. 
Right now, 

     you have to do , like, if there are link changes, do A,B,C,D. You
only want to
     do D.  You don't want A,B,C to occur because that will break
everything you're trying
     to do in NetLMM.

JAK: the question is there was some discussion about, Keith moore wanted
to be able to
    do link identification without prefixes.  This issue is going to
come up if people try
    to do that because, if they try to do it with the same prefixes like
NetLMM it won't
    work.

Sathya: the usefulness of non-prefix linkid is not something anybody has
understood.
    We will need it or not? But we may need it, so we have it open
because of that.
    That's been my opinion always on this.

Vidya: So, I don't have an answer to a problem. But let's be sensitive
to the the fact
   that we don't want to do something for NetLMM alone.   Let's not
write DNA for NetLMM
   I mean, the whole point of NetLMM is that you don't want to use
modified hosts, so
   I don't think the specs should be breaking that assumption.

Hesham: So one thing I don't understand.  So what does having a
non-prefix linkID have
   to do with this problem, because I don't understand, first of all the
dependency,
   with the non-prefix linkid and secondly, I don't understand how
receiving multiple
   LinkIDs while you're still on the same link is actually a good thing.

   I mean you think you're multihomed when that happens.

   What's the definition of that situation?

Sathya: it is not it's greg's suggestion, I'll let greg answer it.

Dave thaler:  on the topic of where the prefixes are not sufficient to
identify the
    link.  NetLMM is not the only case there are cases in mobileip,
there are cases
    in manet and so on, and this is going to be a topic on the INT-AREA
agenda this
    afternoon. So I'd encourage you to come to the last presentation
there and
    participate in that.

Greg: That's actually a really good point. One thing we want to make
sure of is
    that we're changing the right part.  And that will mena the people
who are using these
    technologies have the same model of a link that we do.  So we'll
need to check
    this on list. And we suggest people to subscribe to Int-Area if they
haven't
    already.

3148

Sathya: And james is going to post text on this to the list.

Greg: Yes please that would be great.

Sathya: This is the last slide, but thomas is here, should we go back
through the comments
    again?

    We went through the comments before.

    Should we do it again?

Greg: Talk to thomas after.

Sathya: Should we recap what is the consensus on each of them?

Sathya: (aside) we have time right?

Sathya: Thomas, this is for your benefit on this issue of just sending RS,
      the general feeling is that we should just sned RS, instead of sending
      NS.  Not consensus per se, but the feeling is that we should keep
it like
      this.

      Again on this one, people don't feel that , we already have describing
      this situation,  it's not complicating the situation that much that we
      have to go through and rip the text out to ignore this particular
problem.

      In terms of the text for dealing with broken renumbering items.

      The consensus on this is to change MUST rerun DAD to SHOULD rerun DAD.
      (Don't know if it is MUST rerun DAD, but if it is we'll change it
to should)
      
      And give some text explaining situations where we can describe
where you don't
      have to, for example the situation like where probability is less,
and things
      like that. 

      This one is a little bit more open, it depends on the situation,
and the application,
      so there is no, at least I couldn't discern any clear consensus on
this, but we're
      probably going to discuss this on the list.

      I'm done.

Greg:  OK this is going to be a short presentation, this is part of the
solution space.
      We have a new neighbour discovery option format. It's in a
separate document to
      the DNA solution.  It's in a separate document because it's
referenced by two of
      the documents normatively, and it just describes the new option
format for passing

      (We've renamed it, it people have been calling it TSLLAO Tentative
Source 
      Link-Layer address options.  We've It's no longer TSLLAO as of
      draft-ietf-dna-tentative-00.txt, they're just called tentative
options. and
      you just use them when you're a little bit tentative about putting
a neighbour
      cache entry on someone else, alright?)
     
       the idea of tentative options is that they work EXACTLY the same
way that
      Source Link-Layer Address options, except that ifa host receives a
Tentative Option
       and it already has a neighbour cache entry with a different mac
address, it
      does not update. it discards the update.
       In that case it acts as if no option exists in the solicitation
or advertisment,
      and the document also specifies which packets you can send the
tentative options
      in which are compatible with 2461 neighbour discovery.

      Which means that these options are invisible to 2461 compliant
hosts and they
      do the same operations that are correct for 2461 Neighbour
Discovery, and they give
      added value to those that can read and understand them.  That's
the principle
      thrust of the document.

      There's another ouple of sections about trying to send back
responses even without
      Neighbour cache entries.

      So, it's very short, like 10 pages or less, please read and review
it.  We need
      reviews on this. If we get a couple of good reviews, it's probably
OK to send
      to WG last call.

Thomas Narten: I have one question, I did a quick review of it last
night, and at 
      one level it seems like a fine document, the question I have is up
until now,
      with optimistic DAD, we've taken the position that "do no harm" or
do nothing
      that changes the status of the network until we're really sure.
This document takes
      a step across that line. 

      I think that in particular, if A and B want to communicate, if B
has no information
      about A, and if A sends a Neighbour Solicitation with a tentative
option in it,
      And if B has nothing in its Neighbour Discovery cache, B says let
me add A.

      And my understanding of this is that the Neighbour Cache entry
looks exactly the same
      as the normal one created by neighbour discovery

Greg: Yes.

Thomas:  And this presumably creates new failure or incorrect operation
scenarios that
      we've so far avoided doing.

Greg: Yes, so this is for a node without any existing neoghbour cache
state, not even 
      an incomplete entry for a particular node, and so the device
doesn't have an 
      ongoing session with someone.

      Now you've got a quiet node on the network which actually owns an
address, and you
      come in and you're optimistic and start sending these options to
the router for
      example, and it creates existing neighbour cache state on the
router, which points
      to the new node.

      Now the thing is, you will then do neighbour discovery/Duplicate
Address Detection
      for that optimistic node.

Thomas: What do you mean you will?

Greg: The optimistic Node will do Duplucate Address Detection, and then
the defending 
       quiet node will send a defending Neighbour Advertisement to
All-Nodes' which will
      update all the existing neighbour cache entries and override.

Thomas: So you're relying on the Duplicate Address Detection to be run
in parallel,
      so the incorrect state will be flushed very quickly.

Greg: It will get flushed very very quickly, except the thing is I know
that's not
      guaranteed, but there was no existing neighbour cache state, for
that device.

Thomas: that makes me feel better, in that it significantly lowers the
window of
      incorrectness, if there is one, but it does rely on neighbour
advertisements
      being Multicast

Greg: Yes. Indeed, which happens very rarely, and they are for Duplicate
Address Detection
      only: ff02::1.

Thomas: I'll have to think about that a bit more.

Greg: Is it worth discussing in the document.

Thomas: I think definitely, as in one sense, here is the danger of this
approach,
      but here is why this is acceptable dnager, given this, that and
the other.

   And in particular if it has implications for what is going on in
parallel,
   and if theyhave to be tied together.  There's also a tendency to take
shortcuts
   in that area, for other reasons.  So if they decide they need to take
a shortcut
   in that area, they know it has implications somewhere else.

Greg: I agree with you, we should be very explicit about this.  I think
previously,
   it was a hack, and if we're going to be clever about our hacks, we
have to be
   very very explicit.

Thomas:  I guess at a high level, I guess what I'm (I don't want to say
that I'm
   worried or concerned) but something I do worry about at another level
is that
   we can make DNA and Neighbour Discovery so precise, that what we
expect of the
   behaviour of all of the nodes that to a certain extent we're fooling
ourselves
   in that implementations actually do these thing correctly in all cases.

   And that it may be safer to err on the side of simplicity, rather
than push the
   envelope and hope that people do all the right things in all the
right spaces,
   and what are we solving here? we're trying to solve a round trip?

Greg: and the possible loss of a multicast packet.

Thomas: So the important question is: how important is it for us to
actually have this
   optimization in the first place?

Greg: So, MAY include this option? May take the document and throw it in
the bin?

Thomas:  Well I'd not be in favour of this option being a MAY implement
so much
    as a here's what we think everybody ought to do, or it's not really
worthwhile
    and we don't want to do it at all.

    As Opposed to a MAY, where you run into the situation where you
don't really know
    if people will implement it any more, and you have to deal with the
whole
    spectrum of possibilities.  Which makes it even less predictable even.

Greg: So we need to make sure that 

    Weve probably got two discussions,

    We need to make clear what the failure and recovery cases are.

Thomas: Yes.

Greg: We need to make sure that devices, at least, discuss on the
    list,  and it may be easier just to try and craft text, I'm not
    sure.

  But to describe what ranges of behaviours are likely and describe
   what the issues are for those behaviours.

Thomas: So let me ask another question: Which probably shows my age
    or something, but in the current 2461 world, if a node sends out
    a neighbour solicitation without a Source Link-layer address option,
    where does the neighbour advertisement go to?

Greg: you can only send out a Neighbour Solicitation without an SLLAO
    if it is unicast. Because a multicast MUST contain a Source Link-Layer
    Address option.  So it's a bit annoying, but the Router Solicitation
    is only a SHOULD send the SLLAO.

Thomas: what I'm trying to understand is that suppose this became a document
    and were implemented, what do existing implementations do, and if
another
    node did this tentative option, optimistic DAD and then the DAD, would
    the default behaviour actually be what we want or would we already
    in practice have  a gap where neighbour advertisements are not sent out
    multicast. In which case the assumption that the problem is self
correcting
    is actually not a valid assumption. 

Greg: OK, the neighbour solicitation neighbour advertisement isn't
really the big
    issue here. It's the router solicitation/advertisement that we
actually...

Thomas: It's the router's cache you want to update

Greg: The Router Solicitation is the only one we can effectively do
anything with,

Thomas: because of the option rules, OK.

Greg: The router solicitation allows us to do this and we don't have to
have a fixed
    destination for the router solicitation, and we may have changed
links.  it's 
    not actually a lot of value, to send a neighbour solicitation.  If
we're on the
    same link, we can send the Source Link-Layer Address option, which
means we could
    have sent it multicast any way, so it's only really useful if we're
changing links.

    Now it doesn't hurt if we're on the same link, and the neighbour
cache entry is
    the same right, we just send it with the tentative option instead of
the source
    link-layer option.

    So if we artrive on the new link, and there's no support from the
router, there
    is some question still, whether or not the router will multicast
because it doesn't
    have an existing NCE or it will do neighbour resolution.

    Now I've seen Linux Boxes do neighbour resolution, in fact, I think
that RADVD
    doesn't do any update of the neighbour cache entry when it receives
a router
    solicitation, even with a source link-layer address option.  (except
in my hacky
    implementation). So I've tested this. there are some limitations to the 
    implementation.  There are limitations to how existing
implementations do this.
    It would be good thing I guess, to get a summary of this out on the
list.

Thomas: I think it would be good to understand the target environment
where this should
    work, and whether or not it have the desired impact in all cases.
And go from there
    once we understand all the issues better.
 
Mohan: Not to repeat what thomas said but initially this was meant for
router solicitation,
    and then it was extended for neighbour solicitation right?

    So for router solicitation, case it can be limited to one packet, so
it can be
    done without a neighbour cache entry?  Since that was the original
case I guess.

   If it was only for that case then you wouldn't need a neighbour cache
entry.

Greg: There's a value in keeping neighbour cache entries, in that it
gives you an
     idea of who have been sending router solicitations.  If there are
anonymous
     mechansisms, if there's not state retained, then you can't do rate
limiting
     for example.

     If you have devices come along, and they are getting sent unicast
RAs with no
     neighbour cache state then there is a potential problem

Mohan: But does the DNA spec have anything today,There are like 3 RAs, 
there's no
     other rate limiting is there

Greg: There's not a lot of rate limiting: there's a token bucket on
unicast RAs.

Greg: Anyway, that's a little bit esoteric, really we can discuss that
on list.

Mohan: ...if we feel that there's a danger of creating a neighbour cache
entry,
      that can still be limited as...

Greg: We'll discuss that in-depth on list.  We'll definitely make it two
threads
      I think.

Jinmei: May I make a question for clarification?

     With this mechanism, an optimistic Node sends a unsolicited
Neighbour advertisement
     with this option?

Greg: No, because that won't work.  Node don't always accept unsolicited
neighbour
     advertisements, there's a good reason for that, but what happens is
that 
     because neighbour resolution has to work, they always accept the
neighbour cache
     state change from a solicitation, which may not be a good thing in
general,
     but it's required to work, so if you send a router solicitation or
 a neighbour
     solicitation with a source Link-layer address option, it will
create a STALE
     neighbour cache entry.

Jinmei: So this option is for solicitations?

Greg: This is primarily for solicitations. And if its a Router
Solicitation that's
     typically the way you'd use it.

Jinmei: and if the scenrio where the address is actually a duplicate,
the defending
     node will eventually send a neighbour advertisement to All-Nodes'
multicast address
     with the correct link-layer address, with the override flag set to one.

     Is this the assumption?

Greg: Yes, I mean that the assumption is that DAD defence occurs.  and I
guess that means,
     all nodes receive the neighbour cache update.  Now because it's an
unsolicited NA,
     only those nodes with an existing neighbour cache entry will update
their cache,
     and if they receive the NA should update the incorrect cache entry.

OK?

So we'll take those two issues to the list, and see if we can gravitate
towards 
text ior adecision, based on what we've been discussing.

Suresh:  Last session this draft was presented, about how fmip works
with DNA,
     and got the sense of the room that people were really interested in
this work.
 
     And after that, the conversation degenerated, and people were
talking about
     the FMIP Proposed standard coming out, and that it should include that.

     And then some people said like OK, we don't want big documents, we
want documents
     linked together, and it broke down into a discussion of should we have 
     html RFCs with hyperlinks and stuff like that. So we can finally
get a feel fo
     the room as to whether we want to do this in DNA as a separate
document.

     So, it was adopted as a WG document, I think there was clear enough
consensus
     to adopt it as a WG document, but we want to know how to proceed on
this.

   So if you have any feelings about this now is the time to speak about it.

Hesham: I don't have any feelings, I have thoughts about this.

Greg: That will be a change :)

Hesham: so given the fact that FMIP is being update for PS, and given
how small the
     amount of work to get DNA and FMIP to work together. I mean the new
version of
     FMIP will have optimistic DAD anyway, so I think it makes a lot of
sense to have
     it in FMIP.  It's an integral part of FMIP to detect these changes
quickly,
     and whether the the work is done here and because the work is being
done here,
     for completeness the RFC's being updated anyway, I can't see a
reason why not.

     We don't need multiple documents which update or complement each other.

Rajeev: I think in principle I agree. but it's probably better to have a
standalone
     document which specifies the interaction between two protocols.
     I mean that way we may have to put everything else in FMIP about
how it interacts
     with some other protocol.

     I prefer just documenting these two pages, which it is, today as a
separate document
     I don't think there will be a lot of changes for FMIP PS, I mean
FNA may be made 
     optional. otherwise  I think Optimistic  DAD per se, this document
describes about it,
     saying how you would work with an optimistic address.  So I would
actually prefer 
     leaving it as a standalone document, just to avoid any other
protocol coming in 
     saying how to work with FMIPv6. Either we could put it in an annex
or an 
     Appendix in FMIPv6, saying for clarity, or we presented it here,
just present it
     as an informational anyway.

Hesham: Can I ask? what do you want in this document you wouldn't want
in FMIPv6?

      What would you describe in this document that you should not be
described in FMIPv6?

Rajeev: its set of messages, how you would do FMIPv6 with DNA.
     So I think FMIPv6 should describe FMIPv6 messages, not how it works
with another
     protocol.

Hesham: We do that ll the time for example, with security. We don't
write a separate
     document describing how to use it with IPSec? 

Greg:  Is every Mobility related document going to have a DNA
considerations section?

Rajeev: That's my concern. FMIPv6 should just talk about FMIPv6 protocol
design  rather
      than how it works with other protocols.

JAK: I have a little bit different perspective.
     Because of thetotally antiquated, documentation technology which we
are forced
     to use in the IETF, we don't have hyperlinks, 

??: You should bring it up at the plenary

JAK: I did and I was told to go write a draft on it.

     This basically makes it impossible if you're an implementor to
really know
     in a lot of cases, without doing a full text search through the
IETF archives
     and correlating things.

     So we came to this, I was involved in two design teams in different
working groups,
     and we came to the conclusion that where we could do mix and match
pieces
     or put it in the one draft, we should put it in the one draft,
because of this
     problem therefore I feel that we should have one draft with
describes FMIP
     and where it touches things like security.  I mean security there
are already
     documents outside, becasue there are different ways to do it, but
DNA and 
     optimistic DAD are pretty central to the way FMIP works.

     So I think it should be in there.

Jari Arkko: I'm the incoming Internt Area Director. And it looks like I
will be
      having this group.  We had a discussion with Mark yesterday on
which groups 
      we'll have and I got this one.

Greg: Thanks for your enthusiasm :)

Jari: Its' kind of a new thing for me. I haven't followed this
discussion previously,
      but the question I had was: is this in your charter?  Do you think
it falls under
      the ...?

Greg: We origianlly had intended to have a BCP document, which was in
the charter, and
      as part of that, the original document, we had an appendix which
wasn't developed
      for a long time.  It was Appendix A: FMIP with DNA, and then nothing.

       So we thought it was in the charter, as far as that went.

      Well we thought the BCP document was in the charter, and defining
how DNA interacted
      with existing protocols was probably in the remit of the BCP.

       So whether it's in the charter or not now, has a lot to do with
what the AD
      thinks.

(inaudible speaker) 

Greg: Essentially the BCP was in the charter.  Defining the interaction
with existing
      protocols particularly neighbour discovery but also maybe in this
case.

Thomas (quiet): You shouldn't say was, say is.

Greg:  There are more tenses in Finnish anyway.

Jari: we'll have to take a closer look at this.

Greg: It's the uncertain look in your eyes which is why I'm saying was.

Jari: OK. The other question I have is that you have a lot of documents.
      Do you think it's OK to take on new ones at this time, or should
      you complete the other ones first?

Greg: we're not necessarily opening up new work though.  This was something
      that was planned from the start, so whether or not it's part of an 
      existing document, and whether that document is in mipshop or, whether
      it's here. the work has some interest, I don't know if this is the
right
      time or venue or not.
      
      So that's something we can readily discuss.

Jari: It think the management of where this is and whether it falls under
      the charter needs some further discussion, I'm not personally
      ready to make that decision now.

Greg: Previously people weren't discussing PS FMIP and we wanted to make
sure
      this didn't fall through the cracks.

Thomas:I just wanted to say something based on my former AD hat, and
it's about
     a year ago now, So when we chartered thsi group my belief and my
intention
     was that DNA should be kind of upper layer agnostic, because it's
about to
     be about how IP hosts operate generically, whenever we start to
talk about
     FMIP FMAP or FMAR, or whatever,  I get a little concerned about all
of these
     different ways things are done with DNA because the it's supposed
to be done
     once in one place in the stack and everyone just benefits
transparently.

Greg: Yes, that's I think we'd like.

Rajeev: so a quick response to that is, there's no change of protocol in
any way
      here, we don't specify changes to DNA or FMIP in any way, we just
specify
      the way the protocols work together.

Thomas:  My response to that is, on one level, if it doesn't change the
protcol
      why is it needed. And if the document is needed because the
specification
      isn't clear about what you're supposed to do, then the true nature
of the protocol
      isn't just the on-the wire formats, it's the behaviours that all the 
      implementations have to do.

      If that needs to be specified because it's not clear enough...

Hesham:  Another thing is who are the beneficiaries of this document?

      if it's someone who's going to implement FMIP, and wants to use the
      DNA service, then   wouldn't that be in somewhere the people in FMIP
      are going to read?

Rajeev: That's my concern, I mean how many other protocols are we going
to define
      in their interaction with FMIP.  For security purposes we already
have a
      different document. How you set up security, So we did this
because Originally
      we thought...

Hesham: But that's being don in the same working group.

Greg: Can we please start putting FIFO back in the queue?

Rajeev: I have maybe a couple of comments 

Greg: You're at the front of the queue.

Rajeev: So I think that the context is that we thought we should specify it,
      and that people will keep coming back, it should be documented
somewhere.
      Whether it's in the charter etc, we started with this BCP, and I
don't know
      whether we need to go back and change that bit, or whether mipshop
should
      take it, well mipshop already has a lot of documents too, it has a
pretty full
      charter. So I don't care.  We started here because we wanted to
document this,
      and it's a couple of pages, and it's an informational document.

Greg: Don't go away rajeev, I've got a question.

Vidya: So I apologize that I'm making this statement without reading the
document
      in a long long time.  I sort of share thomas's concern here.  We
don't write
      a document on how a protocol works with neighbour discovery. And...

Greg: Well, recently we have...

Vidya:  Well, bottom line is that we don't have neighbour discovery
considerations 
      sections, and I see DNA as speeding up Neighbour Dsicovery for
mobility and
      handover, and It's kind of disturbing to see that you have to come
up with
      a document which describes how you work with FMIP, HMIP etc,
because aren't
      you then defeating the purpose of DNA?
 
Greg: I guess that there's an essential difference with FMIP.  The
difference is
      that FMIP starts before DNA starts.  The prediction capability
starts before
      you arrive on a link. There's a mismatch there, an existing mismatch.

      whether we think we should document that, as part of theFMIP
process or part
      of the DNA process is another matter.

Vidya:  A quick point on that, james brought up the issue of concerns in
the past where
      you have several documents where things are captured.  I was one
of the people
      who complained on the MIP6 mailing list  that we shouldn't have 10
documents
      describing about the same topic.  However I'm opposed to having an
RFC which 
      is like 120 pages long.  And if we start putting all the protocol
elements 
      and interactions in the FMIPv6 RFC, it will happen.  Which is also
undesirable.
      So from that point of view I do accept that we could keep this as
a separate
      document.

Greg: So the question I have for Rajeev and for the others is: is there
any problem
    with us keeping this as a working group document, it's not going to
require
    a lot of time and care and attention, and the other question is,
    if we keep it, do we have any urgent need to publish as an RFC?

Rajeev: One q at a time?

Greg: Do we have any urgent need to publish the document as an RFC if
we're not going
     to lose state? if we're not going to lose the information in the
document?

Thomas: Can you better define what you mean by urgent need?

Greg: Is anyone using FMIPv6 with DNA or is anyone likely to implement
      in the next 6 months?

Rajeev: We don't know that here though?

Greg: well anyone here going to implement FMIPv6 w/ DNA and they're
willing to say
      it in the room?

Thomas:  I'm not really sure that's the right question, I think the previous
      speakers made a good point, which I wholeheartedly support, about
a balance
      between lots of little documents and a huge behemoth document. But
I think
      it's dangerous to try to make a hard and fast rule about this. 
What I heard
      about this document, the one we're talking about is that it's two
pages long.

      That strikes me as a fine thing to put in the base FMIPv6 spec, if
it's only
      two pages long, and we shouldn't really need to debate about it.
      Clearly this group should review that particular two pages, and
maybe it's
      easier if it's a separate draft and can be put in an appendix
later, but
      at the end of the day, we have to focus on what the specification
implementor
      needs, and having fewer documents is often better than having
something that is
      scattershot. 

Greg: I was trying to figure out. And maybe I left this unsaid.
     I cannot say what mipshop will do with the document, I'm not
offering to
     put it in MIPSHOP because I haven't discussed it with the mipshop
chairs\
     but I think we can hold on to it for the moment, and try to get
something
     done with it.  Does anyone mind if we hold onto the document, and
try to get
     mipshop to adopt it?

Thomas: I guess I don't know what you mean by hold onto it? I mean are
we in danger
     of ejecting it and sending a note to the ID editor?

Greg: Yeah, strike its name, this is anathema...  No, we're not going
     to say that but, I mean we have to put  alittle bit of effort into
     maintaining the document, it has to keep on getting regenerated if
something
     happens to it, you know.

Jari: I 'm not sure it makes a lot of sense to put a little bit of effort
     into something, or to keep a draft around, either we have in interest
     in doing something or we don't.

Greg: OK. Question is, do we go for an RFC in this group? I think there've
     been enough opinions discussed, maybe we can ask for one or two
opinions more,
     and then we can ask for a consensus call because it's pretty clear
people have
     some good strong opinions on this.

Rajeev: I'm the editor of the document. I want to keep the focus of the
document
     on revision of the FMIPv6 specification there, OK.  I think of this
as something
     which people who are using FMIPv6 with DNA may find useful. FMIPv6
can work
     without DNA.

     So I don't see why people want to put this as an additional item in the
     draft revision process. That we are taking there. I think that for pure
     clarity, I think it should be here. And DNA is another protocol
which is
     being worked on, so I hesitate to put it in an FMIPv6 document,
which should
     be focuessed on resolving the issues, we're getting from
implementation experience,
     and things like that and keep that focus.

Alper: Will be the possible RFC informational?

Greg: yes, informational.

Vidya: Given that this particular thing is 2 pages, I can be sympathetic
to it being in
     the draft, however as Rajeev pointed out, DNA is an option,
optional thing for FMIP.
     it doesn't depend on DNA to work.  I know there are a lot of should
and mays and
     there are a lot of optional things in the draft, but personally, if
we consider
     adding two pages.

     If we end up adding 2 pages about everything.

Greg: please be aware DNA is optional for FMIP if you have perfect
information about
     the network you will be visiting.

     Now I don't know much about Perfection?

Vidya: Are we mandating DNA for FMIP?

Greg: are we mandating DNA for Access networks?

Vidya: If we mandate it, it should be in the fmip spec.

Hesham: It's hard to say what should be mandatory in an optimization.
       FMIPv6 can work without DNA , but because it's an optimization,
       how well would it work?

     It's not an on/off switch. there's a spectrum of ways about how,
     things will work.  It's not a good way to describe how it will work
or not
      because there are lots of variations, some [people depending on the 
     deployment scenario, the type of access that you have, different things
     are optional and different things are necessary.

Rajeev: This mandatory thing is debatable, because DNA may not be
available in the
     access network, you need to know what you should do if everything
fails.

Greg: There will still be CPL. You can work DNA with unmodified routers,
theres
      a specification, 

Rajeev: that we can state, but what I'm saying is that if information is not
       available when you move you don't get the performance benefits,
right?
       Right now I don't have to mandate anything, you just fall back to
mobile
       IPv6.  I hesitate to say you should use DNA, when it is
available, but
       I cannot say you must use DNA...

       So that's why I think there's a clear separation here. That's why
I think
       we need a separate document.

Greg: Any more comments?

      So do you think we can make a consensus call on this?

Rajeev: Just to go back on the minutes of the last meeting. there were two
      references on hyperlinks and whether this can be part of FMIPv6,
in the
      last meeting there were two. But, there was consensus.

Greg:  I think that suresh had a listen to the audio, and perhaps there
was something
      missing from the audio...

Rajeev: But if you look at the text notes you can see there.

Suresh: there was consensus, but then the discussion degenerated after, so
       that is why we want to get the real sense again because there was
       consensus before all the  facts were on the table.

       There were some people who had different opinions and didn't express
       them before the consensus was called for. and then they came to
the mike, so.

       that's why we want to get the sense of the room again.

Rajeev: when you ask the question, you can't be sure you know all the
facts into
       the future.

Greg: We've got excellent rear vision.

Thomas: make a proposal on what you want to ask us and the other observation
       I'll make here is that we're spending an awful lot of time on
precess here
       (which is a shame) instead of moving on and doing what's right.

Greg:  OK:  

     Can everyone see that?

Thomas: Is that the only question you're planning on asking?
        Cause I'm not sure this is really the right set of choices.

      (Should we work on DNA/FMIP in this working group)
Greg: No, lets' see what mipshop can do?

      I don't think we should drop the document. Someone has
      to handle it.

Thomas: I think there's agreement on that. you can do a quick question:

       Should this document just be tossed out the window? 
       Or should the work get done somewhere?

Suresh: No, but there was clear consensus on this document should be
worked on.

Thomas: I agree

Suresh: So that question is out of the way, I don't want to call it again,
        because that was very clear, but the only thing which is unclear
is if
        it should be a separate document here or it should be folded
into the
        FMIP spec.

Thomas: And the way you've written the question is not very clear on
that, I mean
        the way I would phrase it is: should we ask mipshop if they will
take this
        on in their documents, or should we take it on ourselves, or
something like
        that. It kind of depends on what they're willing to do?

	it's not like they're going to say: we're not going to touch this one,
        it's your job.

Greg:  well they might...

Thomas:  we can evaluate it.

Rajeev: We can't say MIPSHOP should take it on here.

        Somewhere else is like waving hands...

        We agree that this is something of relevance to DNA.

Thomas: Should it be here? My personal view is that this group should review
         the text, but I think the text itself should end up in the
appropriate
         mipshop document or not?

Question:  Should FMIPv6/DNA be published from here or in a MIPSHOP
document?
       
Greg:   Here are our two options.  this is to get the feel of the
opinion of the
        room (sense of the room).

        Should it be a mipshop document or a DNA document?

<FEEL OF ROOM> 

So  people really think it's a mipshop responsibility. is this correct?

Would you like us to talk to the mipshop chairs?

We'll discuss this offline with the mipshop chairs.
and probably the new AD.
And we'll find a destination for this.  

If it's not mipshop, we'll talk to the AD.

Rajeev: So, You have to ask the MIPSHOP group to figure out?

Greg: Yes.

Rajeev: I'm still confused.

Greg: We're not dropping the document in the mean time.

Rajeev: put it somewhere, but I hesitate to put it in FMIPv6,
     there are other things to do in FMIPv6 than take this up,
     and DNA protocol is still something that's being  worked on

Greg: Yes. I guess we're not suggesting that this is rolled 
    straight into the FMIP document today. If it makes sense at 
    some time to merge them, that's not ncessarily the DNA group's
    choice.

     We'd ask if they could keep and look to publish this,

Thomas: you seem to be implying that there's not enough bandwidth
     to take this on in MIPSHOP, but I also hear it's kind of important
     to the base document.   This should be driven by the community
     that needs it. which I believe is FMIP

Rajeev: I don't know if the community that needs it is FMIP. per se.

    it's both. If they implement DNA and are interested in using Fast
Handoffs.

Thomas: If they're interested in Fast Handoffs, they are FMIP community by
    definition.

Rajeev: I don't know if I can say draw a clean line and say those who want
    FMIP just do this, those who do DNA just do that. I think it's the
interaction,
    which makes it interesting.  FMIP can make use of DNA when it's
available.

Greg: But not vice versa, so it's not necessarily something which is
going to feed
    into the core of DNA ever, so maybe this is the right way to look at it.
    Let's see whether we can get it worked on in MIPSHOP.

Hesham: DNA is the base, and anything else uses DNA. So the users of
FMIP are
    the users of DNA.

Greg: We're very simple here. only the basic stuff.

Greg: So  is that OK? We'll go ahead with that.  Suresh and I will try
and talk to
    Gabriel and Stefano. 

7836

Suresh: We're kind of behind on the milestones, like 1.5-2 years.  

So this is the timeline we came up with. So they're kind of
realistic, so take a look at it.

Greg: If we get acceptance of the MIPSHOP chairs, we'll give FMIPv6 DNA
to them
     that will disappear.

     As described before, we'll try to work out the interaction
     between DNA hosts and Complete Prefix Lists, whether they are
     essentially the same document or two separate documents, they
     may merge as a milestone or may go ahead separately, depending on
     the WG.
7923

sathya:  I'm the editor of DNA hosts.  I don't know if june 2006 is
going to 
     happen.  I don't know if I can just do changes (can't do that right),
     I've been waiting for people to give me some pointers, on that, 
     there isn't really anything happening on that.  And now we have this
     idea of whether we want to merge it with CPL or not (and not enough
     traction on that either).

Suresh: with regard to reviews, there were people who committed to doing
those
     reviews, I guess they were just caught up, so maybe I'll just prod
them.

     I will ask more people to do more reviews, but the merge thing could
     put a spanner in the works.

     So we don't know yet, but this is, kind of what we are thinking,
but could be
     wrong.  That's why it says possible milestones.

Sathya: June 2006, I don't think DNA hosts is likely to, if it merges
and something
     comes out of it before june that's one thing, right, but if CPL is
going to be
     separate and goes in June 2006, I think CPL is in pretty good shape...

     But hosts is not in the same shape to go at the same time.

John Loughney: I was going to comment on a process issue, this seems
like a lot
     of WGLCs running at the same time.  And I'd be worried you can't
get the reviews
     for all of them.

     They probably should be staggered a bit more.

Greg: thanks

Thomas:  Sorry about being late to the meeting, and all, but what I
wanted to find
     out was what was going to happen with all the documents, and how to
merge them
 
     we can do that offline, one fix in a sense is that i would really
like to see
      Routers BCP and Complete Prefix Lists document merged, because at
the end of the
     day, what is it that the implementer wants.

     They want A document for hosts, that's got everything in there and 
     one document for routers.  Everything else is a distraction and
will add confusion

Greg: Actually i think I'd look at it the other way around, I'd think
that hosts
     modifies the hosts behaviour merged in with CPL which is working
with unmodified hosts.

Thomas: One recation, to a comment that was made earlier, my personal
opinion is that
     DNA is an extension to Neighbour Discovery. We want everyone to
implement it.
     We can't mandate it, in a must sense, we can certainly make it a
SHOULD, and 
     hopefully if we make the protcols right, it should be easy to
implement and makes
     sense, it will happen over time, and so we don't want a bunch of
documents you're
     only going to care about this you're only going to care about that, 
     you have choices, because at the end of the day, what we're asking
to implement
     is not that complicated, in some sense.

     So just specify, here's what hosts do, here's 

     and it might be broken up organizationally, because it's convenient,
     in here's how you deal with an unmodified router and here's how you
     handle a modified router.  Except that doesn't the host do the same
     thing in both cases?

     In that case, do it once, and if you get a response in the case the
router
     doesn't understand this, this is how you react, if the router does
implement
     this here's how you react.

     But keep it concise, and here's what we want all hosts to implement.

     And the same goes for routers, here's what you want all routers to
implement.

Greg: Just to clarify, Does that mean essentially the ideal is that we
have a 
     We have the protocol modification? broken into just hosts and routers?

Thomas: I'd be fine at a certain level with a single document but
organizationally
     it makes sense to talk about the router behaviour and the host
behaviour

     because from the implementation perspective, you have two groups of
players
     implementing.

     two documents is a fairly clean split and the other is sections in
the same
     document.

Greg: I'll agree with you, that's how I implemented it.
      I did the routers first and then I did the hosts.

      So it's not particularly onerous to describe it like that, even
including..

Thomas: Right, part of the problem I didn't pay attention to DNA for a
while,
     is you have a lot of documents. and it's easy to take on more work,
     but it's not in the WG's best interest to keep on taking on more
documents
     with overlapping text, and repetitive text.

     Even talking about here, if I look at the list of documents, we
have a bunch of them
     which I don't understand their purpose given that youu just want to
know what
     you need to implement from the host perspective.

     All the other stuff is a distraction.

     Either you need to implement it or not. I've seen plenty of cases
where you put
     something in an obscure RFC and it gets missed.  And that's very
unfortunate, 
     so in some sense, I would like this DNA stuff get folded up into
neighbour
     discovery, and it's in a separate document because it was developed
later.

Greg: I guess that's a similar situation to what happened with SAA
(2462) and ND( 2461)

      2462 is just he hosts' component right?

      Essentially it's how the host interprets what's on the network.
      That's what stateless address autoconfiguration is.

Thomas: Well, the history is more complicated, because there were two
documents originally.
      You could argue it that way, and combine them all in the same
document, and try
      splitting them that way.

      i believe that the structure of the documents is that it's broken
into the routers
      part and the hosts part. 

      I would really like to push the WG in the direction of, if at all
possible,
      just have two documents, and put the essential stuff in there.
Don't put so
      much should and may, and they'll do it.

      Or they won't.

Dave Thaler: So I'd agree with thomas.  It seems you have a huge bunch
of documents
      at about the same stage of progress so it doesn't seem like any
reason in terms
      of mismatch regarding when they're going to be ready to go to not
try to 
      combine them.  So I would strongly like to echo that two documents
would be good.

      One would be OK, I personally prefer two because It's easy to
point people
      at one document, to say this is what I implement, rather than
trying to
      describe things at a finer granularity, like for example with the
node requirements.
      There's the host part of this and the router part of that, so it's
technically, 
      correct to do that, but it's not very convenient.   So two
documents, and you
      say here's the RFC implement that, oh router guy here's the RFC
implement 
      everything that's in there.

      So I would like to compress as much stuff as possible into two
documents, but 
      preferably not into one. 
(inaudible)

      Exactly, So they're checkboxes and when people come up to the
checkbox list
      they don't go to the correct granularity, they don't say when you
implement
      MLD you have two check boxes for the router side versus the hosts
side. they
      say do you support 3810?  And you just have one checkbox there.

      And so for getting people to do the right thing there, with
implementations and
      compliance things, its helpful to have one RFC per requirements set.

Erik: So we talked about this stuff earlier, but I guess thomas wasn't
here then,
      I think that splitting it into the hosts/router one doesn't make
any sense, because
      if I did that to neighbour discovery, the thing would be a mess.
       Because you'd have to decide where to put the packet formats.
      If you're going to describe and you also have to figure out how
are the people
      going to read the document so that they can understand it, you're
going to need
      some high level explanations of what typically happens as part of
the introduction,
      before you get into the details of the protocol. 

       So if you're talking about a protocol where two parties implement
different
      pieces of it, Having the two piece actually be in the same
document makes a lot
      of sense.  Because that way it goes with the packet formats as well.

      So the comments I made earlier was that yes I think we should
write the documents
      with the implementor in mind.  It's not clear to me whether that
means it's
      optimal to have one document that covers all the pieces.

      I do care about whether one can in a sensible way, with
consistency between
      documents, have multiple documents that specify the different
pieces, right?
      What I care as implementors is actually not having to read between
the lines, 

      and deal with inconsistencies between documents, because I expect
the implementors
      to want to implement something, like a host implementor, wanting
to deal both with
      the case, when the routers are not modified and the routers are
modified.

      Today our chair postulated that he could figure it out, but just
reading the
      documents, it might be hard, right?

      I'm not sure how many documents it needs to be, it may make sense
to do a high-level
      view of what would actually the flow be, and think about it as
here's the order that
      one would read things, in terms of sections and then come to maybe
this piece is
      standalone enough that we could have it be a separate document we
could refer to.

      Or perhaps not, because if it becomes a 200 page document, it
becomes hard to 
      get people to review even pieces of it.

Greg:  I know what you mean. I've been reading 80 page documents
recently, and it's 
       quite hard in some cases.

Erik:  It's easy to have a thirty page document, making a detailed
review of the pieces,
       and have someone lese look at how do the pieces fit together right?

Greg: we actually had a document in the charter the solution framework.
which was
       supposed to be a high level overview of what you need to do. 
That we got
      distracted by looking at all the details for a while.  I think
that's what happened.

      It's lapsed.

Erik: but I also don't know if that's the right model in terms of
carving things up.
      Maybe sitting down and doing the high level here's the set of
thiongs we need to 
      implement on a host or on a router. 

      Now are there pieces which make sense to be standalone.  Because
having a 5 page
      introduction that doesn't say much but refers to a bunch of other
documents,
      might not be sort of helpful, right?

      Maybe there has to be a bit more meat.

Greg: I get the feeling that we're not ready to redo the charter
discsussion completely,

       I think we need to do some charter discussion on-list and see if
we have a feasible
      way forward.
      I don't think anyone's arguing we avoid doing this for
implementors.  Everyone's
      got the same idea.

      So let's see what we can do to get the basic form of what we need
to give the
      implementors.  I think that's the straightforward thing to do.

      And let's do that on the list in March (Note !)

      The first cut, w'eve got to start the discussion sometime, right.

      Please approach me or any other likely suspects about this.  We'll
natter on, and
      get some things on list soon.

      I don't see any other way forward than to take this to the list.
      Does anyone else have an opinion?

      Previously we've had very small groups of people actively
involved, and not
      necessarily discussing things on list this is critical for the
function of the
      working group, this has to be done on-list.

      If there's anything you can't say on-list, then consider not
saying it.

      So what we'll do is discuss this on-list as much as possible and get
      everyone involved. If you've got an opinion, please say something.

Sathya:  I just wanted to say. the routers BCP, isn't targeted at
implementers,
      there was a discussion on this in washington I think.  And that's
why we
      split that off.  So I think the routers BCP stays separate,

Greg: as an administrative thing.

Sathya: and so two documents for routers and hosts, doesn't...

Greg: It's what prefixes and what timers, that you can set using existing
       neighbour discovery to make DNA more efficient.

Sathya: The router BCP does stay.  Leaving one other document for the
routers
    and for the hosts would ideally be great but, I don't know, the solution
    document has both routers and hosts in it.

     But if you look at DNA hosts and CPL, it's targeted towards unmodified
    routers, so the solution document like erik mentioned about
neighbour discovery,
    has both router behaviour and host behaviour for modifyin everything.

     hosts and CPL are for unmodified everything..

Greg: we might have to completely discard the idea of the existing
documents that
     we have, and just figure out what we want.

     And the reason why we've got the documents today is historical based on
     how things developed.

     We've essentially got enough knowledge now to decide what we want
and just do it.

     That might mean that text isn't shared between the documents.  It
might mean
     we just read the documents we write the text which we need, right,
and we do a
     good job of editing them. 

     I think that's reasonable don't you?

Sathya: I don't know if you want to start from scratch?

greg: we're not necesarily starting from scratch, there's just no
    guaranteed path for text to move out of one document and into another.

Sathya:I don't mind for the host, but the solutions document.

Greg: yes, I understand there was a design team, 

     and what i'm trying to say is that if we're convinced a certain
     piece of text is necessary, it goes into the document.

     And the structure may be correct in the hosts, may be correct
     in the protocol, but let's just work out what structure we need.

Thomas Narten here:  I came up here originally to echo Erik's comment
     that where the packet formats go is a problem, But I think it's
     important to have a high level overview is really good, and I 
     actually wrote a bunch of text and wrote it on list, and I would
     be very happy to continue to expand on it because it's very useful
     for someone to be able to read all that and understand at a higher
     level what is going on, and how things are supposed to work.

Greg:  I think that Erik and JinHyeock did a job before of initially
     outlining which documents things were in, but also, placing a
description
     of what's supposed to happen.  The solution framework document.

     It might be good to talk to those guys about it.

Mohan:  So you tlaked about the solution document splitting it into two.
     I think that may be quite difficult, right, because last time when I
     read it I had to go back to the previous section, it's very difficult
     to read just one piece.

greg: Is that a problem with the document or the ...

Mohan: it's just very diffcult to.  When you ay the hosts' behaviour, I
would
     like to know how the text was written for the routers. it's part of the
     review, I'm not sure.  So keeping that as two separate documents, makes
     little sense to me, I don't know.

Suresh: we have not decided on two documents, that's still open to
discussion.

Erik: one other comment on DNA routers. Maybe we should rename that one
because
      it's really about operational considerations.  

Greg: for networks supporting DNA.

Erik: Yeah.  And calling it routers makes people think it's something
you implement
     in a router.
9407

Greg: networks, OP networks or something.

Sathya: I just want ot agree with mohan on this, the solution part
splitting it into
      routers and hosts won't work.  Erik made a comment like, neighbour
discovery
      being unreadable with the packet formats.

      It is the unmodified routers portion of this which is a mess now,
and we don't
      know how, to some extent I'm in favour of merging them, but I'm
open to other
      reasons why we should not.
      
(inaudible) 

      talking abouthosts and CPL.

Greg: Let's just figure out what we need to tell people and figure out
the top level
      of what we need to tell people, figure out the ways we want to
split it, 
      There'll be a couple of different ways, and then we'll split it.

      and then we'll see which documents fall where.

      So if we can forget about the documents, and know we've got enough
knowledge
      and text to start putting in the final document, whetever it is, I
think that
      we'll make some progress.

Any other comments?

Thanks very much,  We'll see you in Montreal.