[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA-BOF] Draft Minutes from IETF 58 Session
Hi,
Here are the minutes from the session at IETF 58,
ably taken by Ted Lemon.
Some of the speakers weren't able to be identified,
so please look through and indicate if you made
one of the unattributed comments.
Also if there's a statement which you think needs clarification,
please e-mail me. I'll be getting this submitted tomorrow,
for the proceedings.
DNA BoF - 2003/11/11 - notes by Ted Lemon
Minutes.
-------
Introduction by Greg Daley
Session Chairs: Greg Daley (GD) + Pekka Nikander (PN).
GD: Status reports -
for proposed charter items for detecting network attachment.
DNAv4 Looks like it's gonna be in DHCwg.
- we'll have an update here though.
(Presentation by Bernard Aboba)
DNAv6 Problem Statement coming up, but not in repository.
(Presentation by JinHyeock Choi)
IPv6 DAD Optimization Goals and Requirements out.
(Presentation by Daniel Park)
Link layer hints -
Paramters for L2 Hints
(Presentation by Nicola Montavont)
Link Layer hints for DNA
(Presentation by Alper Yegin)
We'll have the discussion of these two together.
JinHyoeck Choi (JH): DNA for IPv6 problem statement presentation
(Talking about movement detection and existing
problems in Mobile IPv6.
Then DNA for IPv6.)
Bernard Aboba(BA): Why use network unreachability, why not send RS/RA
message immediately?
We do this in v4 because we don't have RS/RA.
JH: If you have two routers, this could cause problems
if the wrong one answers first.
GD: Answer: this was defined as the reachability test
in RFC2461. Also mentioned in MIPv6.
???: What is the reason for that?
if you have 50 users on an access point, it goes
down, comes back. There have been extensive
discussions on this. First check new link,
*then* do RS/RA.
Bernard Aboba - DNA in IPv4 presentation
issues list is at:
http://www.drizzle.com/~aboba/DNA/dnaissues.html.
Ted Lemon (TL): What about hysteresis?
GD: We should talk about this on the mailing list.
TL: Use a well-known address for source?
GD: Not convinced that's useful in all cases.
Could use one of the reserved IPv4ll addresses.
James Kempf (JK): Bernard made the point that hints need to be
verified.
In GPRS&CDMA2k, my understanding is that if you get
information in those networks it doesn't have to be
verified, because the network controls where you
are going, and if it tells you something, it's not
wrong.
802.11 is very different. Very little indication of
how to map to the IP layer, it's very complicated.
I think movement detection is a kind of a misnomer
because you're really moving at layer two, and
your routing's changing or not at layer three.
So you're trying to detect routing change, or need
to take action to change routing (mobile IP). So
in first two cases you can use info in these
triggers to reliably determine whether you need to
change your routing. In last case you need to
probe, etc.
Speaker???: Trigger just says your link has changed, layer up
has to determine what to do next.
???: PPP link going down/up in CDMA2k is reliable
indication you have to do something.
BA: I think there's a distinction between indication
that something's changed, which might be reliable,
and indication that you have meaningful layer three
connectivity. You get an IP address, but you don't
have reachability. Helpful for multihoming case.
???(same): There might be two ppp links of interest, one
between laptop and phone, other between phone and
network.
Greg: There's a distinction between routing func and ppp
func.
We have a bof which has a fairly diverse set of
goals. Looks like DNAv4 stays in DHC.
Can DNAv6 be a goal in itself? Does DAD
optimization belong here? I think there's
interest enough in link hints to do a catalog.
I don't think there's a lot of reason to go deep
into abstractions. We might just be doing the
wrong thing.
James Cabgan(JC): I think one of the problems with this whole topic
area is that IETF can't solve the problem.
Problem is in 802.11, which doesn't give host
enough information.
I think the problem is that if we start a WG and
from the get-go it's apparent that the most
difficult part of the problem is something that
we can't solve, it's kind of setting ourselves up
for frustration.
So it's important to know what part we can't solve,
and not try to solve it, but to instead focus on
the part we can solve.
Thomas Narten (TN): Agree with James to some degree. This business of
link hints is potentially useful to catalog and
describe so people understand it, but ultimately
the stuff that goes on in L2 we don't have much
influence over. We can determine if we are on the
same IP link as before.
If we can make improvements there, we've done
something positive.
???: The link hints problem there are other parts of
IETF can benefit. Agree it's hard to solve. If
you take fast handoff work, I think that the link
hints is a very critical piece of the solution,
particularly handoffs across different types of
technology. Would be good if IETF takes an
approach. Depends on how you scope the
problem - create an abstraction that doesn't depend
specifically on IEEE stuff. Work is very useful.
BA: Part of the reason nothing's come out of it, you
have to look very closely at the application. For
TCP it might mean something very different than
for DNA.
In particular, some of the discussions Greg has
been having, what are you proving? I think it's
relevant.
It doesn't take an enormous amount of effort to
answer the question of what to do with each hint.
RAID or signal strength.
TN: One thing I do get a little nervous about is when
people say L2 triggers or hints are critical to
making this stuff work.
???: Proprietary mechanisms of detecting triggers can be
developed.
Question is, can we have a standard way of doing
it?
GD: Quite possibly correct--we're the puny weaklings.
But talking to IEEE and knowing what we want does
help.
???: Is there a problem in talking to IEEE?
GD: I think we can do it. Whether DNA is right group
I don't know.
TN: Wary of IETF trying to come up with consensus on
what to tell IEEE in this space. Easiest way to
make progress is to just go over there and make
the arguments.
GD: Can we leave comments to those who are standing up?
Brajesh Kumar(BK): 802.11 could use for any technology. PPP
establishment is a fairly strong hint. So even if
perhaps we get no strong hint from 802.11 now.
If we can articulate the problem there maybe we can
be more useful in that context. We should not be
scared of any of the problems just because we have
no mechanisms from link layer yet to resolve them.
James (Caghban?): Bernard and I are working on stuff with IEEE.
Situation is that right now as you have described
it's pretty bad with 802.11.
802.16 nobody's looked at. 802.20 is coming.
Whole list of possible protocols that might need
some work.
Obviously IETF is not going to get into that.
Somehow we have to figure out some way that they
can get their process to deal with it.
We did this quite successfully with 3gpp. Would
like to do something similar with this.
BA: There's ways to go about this. Instances where
IETF has been able to give guidance. Pilc -
advice for link designers. If someone were
designing a link in the future, might help.
Having been in sessions, not sure the help we'll
provide will be worse than the disease.
They're looking at a whole bunch of things
including changing the IETF's use of triggers.
Important to tease out fundamental principles,
don't need to characterize everything.
<moving along>
GD: Opinion on where IPv6 DAD should be done?
TN: I have opinions, but at some level either group
could do work, it's a management decision where
it's got best chance of success. The high level
bit is that this problem needs to be solved, we
need to give it a home.
GD: Ask room?
PN: I guess if we are going to ask room opinion we need
more background.
TN: Then we should just go on, maybe - might take too
long.
???: Are you talking about defining requirements?
GD: Idea was that there were at least two drafts which
would be pushed forward at this time try and get
some idea of the goals or requirements and get a
candidate DAD optimization spec. Any additional
stuff if there's different properties we can have
a look at those.
At least get something to go towards standards
track. People are screaming for it.
TN: My assumption is make sure we have a clear problem
statement, and we develop a solution in the
standards track.
PN: Here's a brief summary. I think there are two
major issues. One is IETF ask for working group,
we really should focus on IP layer. We should not
go too far to link-layer issues. Second thing,
there is pretty strong interest in these link-layer
issues, definitely a need for some kind of liason
to IEEE.
Whether it's a WG job or belongs to some other
part of IETF needs to be clarified. If we are
progressing towards WG, safer way is to focus on
IP layer issues.
But both should be addressed in some way.
???: Might be useful for wg to catalog what hints might
be useful, give it to whoever goes to IEEE.
???: One thing on link layer hints, no other group
looking at this issue. Main user of those hints
will be the DNA group, I think those drafts are
very useful.
We have to not only catalog all those hints, but
what use they are.
Speaker: Two parts - identify what is out there, how we use
it in DNA. Second, what else could be helpful?
Falls beyond the boundaries of IETF. If we are
not going to do the first part, are we going to
completely ignore what we can get out of link
layer? Purely network layer?
GD: I think there's ways of dividing this sort of work
in network layer.
???: I think that even if you cannot change what is
being standards, you can leave implementors some
guidelines on how to implement interaction between
link two and link three. I think the point is not
about trying to change what we are doing, but
trying to abstract some guidelines.
GD: We've got to wrap this up. Please get on list,
say if you want it a WG. Input in charter needed,
or you will get a bad WG or no WG.