DNA working group meeting
Chairs:Greg Daley, Suresh Krishnan
Minutes: James Kempf, Mohon Parasarathy
Discussion of agenda
Additon of some items
- call for reviewers
- tentative option
- milestones
-------------------------
Link call draft sent to IESG , LC approved
CPL sent outside for review, not much changes, just clarfications.
Ready to go. Make consensus call on the list to check for more
comments.
FRD document as WG document in the last meeting.
draft-ietf-dna-frd-00.txt
Please take a look at the IPR, filed in Korea.
discussion of drafts
- WG last call on Alper's draft complete, to IESG
- CPL draft to last call
Last meeting, FRD is WG doc, review needed.
DNA hosts draft updated:
Presentation by Sathya
----------------------
draft-ietf-dna-hosts-02.txt
We made the DNA steps explicit..
there are 3 steps.
- To see if you have cached information and make use of it. If there is no information,
- make all the addresses as optimistics
- Conduct link identification
Prior info stored related to the links the host visited in the past
- link change or no useful prior info, follow procedure below
Link change
-Change IP config
- configure DAD
- MLD
Non link change
-Restore address config state of all addresses
- Conduct reachability detection to one of default router
Editorial changes
-------------------
We don't say anything for MLD join for solicited multicast address when setting
to optimistic:
proposed text from ErikN's email:
- Host must send MLD join for the solicited node multicast group before
sending RS message for the CPL
Erik Nordmark
- Not before RS, but MUST before DAD NS (It MUST be done before RS or NS.)
Sathya
- Do it before sending RS. .
- After change state to optimistic
Erik Nordmark
- Doesn't have to be that early. Can stay in optimistic forever, but ND is
inefficient, can't send NS, must send packets to router. Constraint is loose,
important that it gets sent and then send DAD probe, then wait for a second.
Might be later
Greg
- Tight constraints on this. Need to send before the RS. Presentation later,
has to do with snooping switches
Other changtes
- Editorial
- Diff (will send link to mailing list)
Next presentation
Nicolas Montavont
Router BCP Update
------------------
Brief update draft-ietf-dna-routers-01.txt
Did not make many changes
Removed section on Disjoint admin
about: - Routers should not advertise that belongs to different admin
Anything else needed here? (No comment)
Removed background w.o. recommendations
-Diff (will be posted to list)
Greg: Review needed on both docs, contact chairs if you want to review
Want to get docs advanced soon
DNA relocation delays
---------------------
draft-vogt-dna-relocation-01.txt
Presentation by Greg, doc written by Chris Vogt, et. al.
addresses MLD join issue in Sathya's presentation..
--------------------------
The problem:
When we change POA, determine IP address change very fast. Involves
IPV6 RD, ND,
- MN configures new address, etc.
RS (TSLLAO) from MN to AR
RA back (content depends on router on access link)
after reception of RA, additional addr and routing config
IP reattachment, BU etc. may happen after that..
The problem:
Optimistic Addresses need to go through optimistic DAD
Sending NS requires prior transmission of MLD Reprot
MLD Report should be randomly delayed up to 1 second during interface intialization
(RFC 2461/2462 bis)
Objective of delays to desync simultaneous bootup of multiple hosts
- but it prevents fast IP reattachment due to MLD Report delay
Erik Nordmark:
Power goes, power comes back up, all hosts will send at the same.
- Delay was there to introduce cthe concern.
- key word is interface initialization. Moving, not
- Not bringing interface up and down when moving
- When you are moving around, this delay may not be needed.
GReg: Still need to say something
Erik : Just say that DNA does not ....
Hesham Soliman
Adding something to 2461bis would make sense ?
- saying don't do if MN
Greg
It has to be in 2462bis or MLD ?
- Would need in MLD also
Hesham
- Don't think it needs to be in MLD...
Greg:
delay is in MLD also
Jinmae
- 2462bis, matter of RA
- Current draft req. on amount of delay for MLD transmission when reiniting the interface
- discuss in IPv6 WG, Our (IPv6) consensus is that it is too late
to change in rfc 2462. random delay remains, will remain in RFC.
This delay is not needed (Personal). No clear consensus on IPv6 WG.
Greg: We have to make some decision.
Jinmae
- Trying to clarify
Greg
-This might be where to do it,
Goal of this draft is to make recommendations
Mohan
- Is delay not needed?
Jinmae
- Clarification makes sense.
Greg
- No impediment from IPv6 WG, should we do it.
Hesham
- Erik's point, discussion on RSes and soforth, global clarification that chaning
APs and interface init are not the same thing. Don't put same constraints
on moving between APs as on init
Greg continues
MLD report sent before oDAD NS, delay is not necessary
RS is tricky one
RS/RA - no additional messages between them.
Router understands the tentative options and hence sends RA. If the router does not
understand TSLLAO, things may not work.
If not, can't push LL addr, which would lead to NS/NA exchange which would need
MLD report
Solution:
Omit delay for initial MLD Report upon movement
there might already be desynch at the link layer when you attach from moving
Start optimistic DAD before initial NS, use for RS prior to NS for oDAD
Erik Nordmark comments
----------------------
oDAD is set up so you don't have to complete before you send RS/RA. Questions about
wording in spec, oDAD spoec still says you must send NS when you go optimistic.
Can go into optimistic mode, send RS, then MLD Report. If RA says didn't move,
turn off optimistic mode
Greg
Cost of opti mode is low enpough that you can stay in as long as needed
Erik
If router supports DNA, you get response immediately
Mohan
RS/RA, then do MLD
Greg
Not sure
MLD snooping switch, multicast is not treated like broadcast, then switches
need to have multicast group state, need to send MLD group join at new port
before you can send NS. Legacy router, will try multicast delivery or unicast
delivery RA with NC entry. Snooping switch won't get NS.
Erik
MLD group join, won't get NS if router sends it (due to lack of NC entry),
because snooping switch doesn't have state
Greg: MLD required only for solicited node multicast..
Erik
Ignoring SNMCaddr, moved or didn't, hint is layer 2 move. Need to send MLD reports for all. Movement at L2 matters for snooping switches.
Greg
To get RA, only intereseted in NS, so only interested in SNMCaddr
Erik
But what about other multicast groups, don't know if switches are snooping, can't
tell if moved port
Brett Petland
DNA router will support tentative options
If not, normal response would be multicast
Greg
Assuming multicast for legacy routers, don't have snooping switch networks
Hesham
Router only send multicast if scheduled to send, normal behavior is to send unicast
to solicitor.
Mohan
SHOULD in 2641
Erik
Legacy router sees no don;t understand TSLLAO. either needs to resolve with NS or
multicast the RA back
Question, if you have legacy router, if it tries to unicast (sends NS),
then host sends RS. Host sends RS, doesn't see response because switch drops
multicast. Need to do the MLD at some point in time.
Hesham
Eventually recover on multicast RA
Bigger problem with MLD in general, manditory part of spec, need link layer trigger
Hesham : eventually Router might send a RA.
MLD in general. MLD and snooping switch. If the interface goes up and
down, then need to do elaborate procedure of joining all groups..
Subdir Das
How do you know interface went down and came up.
Greg
WG doc describes link indications (could look at DNA triggers)
Subdir
Reduce delay for MLD, special case for interface already up, how do you
distinguish that it is a special case? Hard to special case.
Greg
We are already making a special case..
Already using special case for RS
Subdir
Generic problem, synch is a problem, don't know how many MN are doing it
Greg
MLD problem might be solved here or somewhere else
Sathya
2 questions on MLD join. Neither question are answered in host BCP. What should be done?
Greg
suggestions about general guidance for difference between reiniting and moving.
Is that something we should look at? Difference in delays should be identified.
Might not be explict DNA thing.
Sathya: should do in DNA?
Hesham : Years of confusion in interface goes up/down, should be done in DNA.
Sathya
We can try to put into host BCP draft
Greg
Or possibly MLD draft
Sathya
MLD join, done when L2 hint or? Quesions are open.
Suresh
Suresh : Right place to address is DNA and not IPv6 because IPv6 is not worried
about getting the documents out so fast..
a reference is not very good. Should address in DNA.
Hesham
Sounds as if a generic issue for MLD with snooping switches
Suresh
Not fast enough for us, it is in MLDv2bis but it is not clear for movement.
Ref in 3590.
Rajeev Koodli
Router gets RS with temp SLLA, repsond with RA to that address or send multicast.
Can it do an NS?
Greg: Yes, the receipient can do an NA with override flag reset
Rajeev
What is requirement for node that hasn't sent MLD
Greg
distinction if multi or uni. some daemons don't know if there's a NC entry
Rajeev
NS, address is still optimistic.
Greg
Recpipiet can do NA w.o. setting NC enttry
Rejeev
Before RS, set to optimistic
Greg
Dosn't need to send NS right away, incorporate guidance deferral of
NS whether or not separate guidance for MLD, another story
(sense of room)
Distinct problem that generic guidance for difference between movement and
initialization, and document.
(hum) - nobody against
Next question
Separate document to describe guidance for differences between movement and
initialization.
separate doc: (confusion on question)
Sathya : Host BCP document. Adding more drafts is not good.
Brett: Applies to both BCP and Solution dradft.
(Greg puts the question into a slide)
a) separate document
b) PUt in existing DNA docs.
Pat Stevens (HMS)
There might be scenarios where there might be an interface going up and down
Might not know if transmission event, might look like movement but
might be same behavior like up and down. All hosts lose connectivity,
looks like a mobility event, but same behavior as interface up and down
Greg
Looked at it for 11b, same for BS failure and everyone moving out of
range at same time, missing beacon, etc. Devices moved out of range
simultaneously. In 11b, serialization done at 802.11b probe phase
did some serialization: LL desyncs. Some link layers will sync, but
with certain MACs, will desync.
Hesham
Also most MAC layers, handled by MAC. If you're already assoc with AP,
lose AP and comes back up, no contention based access. If you need to
go through contention based access, problem.
Greg
Point well taken. We will say clearly that "If the link layer is
desynchronised.." do the following..
Same document or Existing document ?
Back to concensus call
A) Separate document : No Hum.
B) Existing Document : Hum.
Which doc?
a) drafct-vogt-dna-reloc?
b) draft-dna-hosts
Hesham
draft-vogt is not a WG document, so not "existing"
Suresh
draft-vogt solves two problems
Jinmae
Question, what is DNS hosts BCP for? Can be regarded as protocol
change or variation, might not best if protocol change
Greg:
hosts document is a BCP and not standards track.
We can make hosts doc standards track if necessary
Hesham
More general concept. And not specific to vogt*. Need to describe
how you know diff between init and mobility, makes sense for generic doc
Greg: Do you think it is a DNA thing ?
Hesham: Yes, it is.
Sathya
Suggestion. Don't get working group consensus yet ? Don't know
what is described in these documents.
Have people working on docs work this out.
Greg
----
Who thinks we have enough understanding to make a decision?
do: no hum
dont': (hum)
Group consensus is that there is not enough understanding about what is
contained in these documents.
Take it to the list.
Sathya
Talk on the list about when MLD join should be done
(Next topic)
Rajeev Koodli
FMIPv6 and DNA
--------------
FMIPv6 usage with DNA protocol
Presented this at Paris,
To document how FMIPv6 can be used with DNA ?
FMIPv6 makes use of neighborhood information to expedite handovers ?
FMIPv6 makes use of neighborhood info to expedite handovers - resolve AP
ids to router mac and IP addrs
DNA provides fast movment detection across subnets
Scenarios where neighborhood information is not avaialble, DNA
Nhood info might not be available, DNA can assist reacitve handover
(description of protocol)
can help fast reactive handover MN associated with Access point
and obtains the AP-ID, Ar-info, if information not available use DNA
Rtr solicitation with DNA extension
configures address,
MN sends a FBU to PAR directly
PAR sends HI message, Handover acknoweldge message
PAR sends FBA
PAR starts tunneling packets to MN's new COA
Current spec, encap fast BU inside FNA, if oDAD used might cause collison,
but no fifference with normal oDAD
Suresh: Informational document. How many folks have read the draft ?
- couple of folks.
Accept as WG item ?
Suresh: Useful to document? (30 hands)
Not interested? (no hands)
Interest in doing work
There is interest in pursuing this work.
Hesham : RFC 4068 is being updated. Done there or here ?
Hesham
4068 is being updated. Should it be done in 4086 or here?
Rajeev
Why do it here? No protocol modifications, just documenting steps.
DNA is right place to do it. Can reference, if you resort to DNA, here is how to do it.
Question
Should this document in DNA WG? 12
Do elsewhere? 3 hands
Concensus to work on here
James Kempf : Splitting the work into multiple documents makes it hard..
No Hyper links. Searching too many bits..
Rajeev: Instead of cleaning separate protocols, have a single monster.
No normative dependency.
Greg: We don't have to push this if FMIPv6 comes out as proposed standard
Brett Pentland
Solution document presentation, draft-pentland-dna-protocol3-00.txt
Background
Based on two piror proposals
(describes FastRA)
(describes link idnentification, landmark prefix)
Description :
FAST RA and link-id
Fast RA: Calculate token based on RAs from other routers and RS and calculate token
Link-identification :
- routers listen to all prefixes on the link
- new option for learned prefixes
- one of them is marked as link-ID prefix
- hosts include a landmark
- landmark yes or no
- unsolicited RAs may carry a subset of prefixes but must include a link-id
prefix
Link Identification:
- RAs include a link-id prefix
- moving to new AP still includes the prefix,
Issues:
Identification based on non-prefix information, no supporting emails on ml
Explicit link-identifiers - mark the prefix: alt non prefix (biggest issue)
TSLLAO option, where does it belong
Delivery of MLD packets during DNA (presentation to follow)
Erik
Where is the TSLLAO draft?
Greg
Not in any WG, individual w. IPv6 tag. Separate draft, may need to have it
separate if additional uses. Primary use DNA, include in base DNA spec.
Generally applicable w. oDAD, send unicast NS, send this option instead
of destructive source link layer document.
Suresh : How many have read the document ?
Suresh : People with issues last time, are the issues solved now?
Should we adopt this as WG document ? 23
NO : zero
Consensus to accept it as WG document.
Non-prefix link identifiers :
-----------------------------
Racquel Morera:
Could be useful in adhoc networks. Explicit link ids could be useful, could
be easier to include now.
Brett
OK to be an explict prefix id
Brett: Can RS/RA even work in adhoc network ?
JinHyeockChoi : DNA is good with explicit link identifier. Host can check for
link change for link identifier even for RA. Linkid
Racquel:
Not based on prefixes
Greg
Questions to resolve in adhoc
JinHyeock
Link id, explict id is more friendly to ad hoc environment, host can check
with complete RA. Link id is landmark prefix, prefix all routers know,
link id prefix is natural choice. W. explicit link id more gracefully
deal with link prefixes changes.
Greg
Some crossover, need to figure whether we need first, non prefix, or whether
simpler to incorporate now.
Brett
Mesh networks, RS/RA, is this compatible with mesh
Nonprefix ids, still might need explict w.o. nonprefix (i.e. explict but prefix)
Erik
prefix like ids but not a prefix. Don't know what ad hoc is. If you need to assign
some form of id, does it have to be different than 128 bits? Can you use ULAs, but
not too many. Don't set L or A bit. As long as I can use as link id, just use with
DNA. Don't know what might be needed, keep door open. Only used for link id
purposes. Don't know requirements.
Brett
Explicit link id in router advert, rather than using prefix from prefix list?
Erik
ULAs are just prefixes, bit that says its a link id, but not a routing prefix
to say that don't use it for other purposes. But don't know enough about
requirements.
Brett
Hosts don't know that there is a link id, do hosts need to understand what is
the link identifier.
Suresh: Pick a 128 identifier,looks like a prefix, mark as not a prefix,
someone will still use it.
We don't know enough about it to work on it, so I think we should postpone.
Another issue, how do we come up with this link id, manually configure, we are
not ready to work on this.
JinHyeock
Agree these are issues, but Greg suggests scheme to solve two at once
Sathya: Two problems
Agree w. Suresh. One, devices agreeing on common id to define link,
having separation between routers and hosts, no definition from
ad hoc network point of view, open for ad hoc. We are just trying for small
forward compatibility, add a it somewhere. Will this make a difference?
Greg
(as nonchair) If we wanted to do nonprefix link id, we would need to track validity of id separately from prefixes, not something that we have not really done much on. Would it be OK to add nonprefix ids later as an option. Absence of nonprefix, use prefix ids only for DNA.
Brett
Are you saying that we should have an explicit link identifier?
Greg
If we don't know how to do this now, we can get away with not defining these now, add explicit link id, we could add it in later, won't hurt operation of this draft.
Brett
Then would redo DNA
Greg
No, just nonprefix link identification
Sathya
Wouldn't overlap condition on hosts still apply? One router with idnentifer?
JinHyeock
Agree with Sathya
Hesham : Use some bit for indicating the DNA operation.
Mohan
New bit, needs to be present in all adverts
Brett
Just an entry in prefix list though not a prefix
JinHyeock
Ad hoc, not clear what is valid link configuration. Wait until it becomes clearer.
Hesham
Do we need to add even later? Can have prefix, enough flags to indicate to use for
autoconfig or not. Use for either case. Diff is can you use it for generating addresses.
Sathya
How can you solve this problem? Smallest prefix is fine, just stick with that.
Change will not be that costly on existing. Lot more changes on router behavior,
agree on an id, etc. not suggesting this.
JinHyeock
Not necessary to define a new id, whether to announce explicitly
Suresh
Don't mandate if use prefix as link identifier, could be a link identifier.
Sathya
Say that it is lowest prefix, but can change it.
Suresh
Don't tightly couple. Decouple
Mohan and Suresh argue about how to do this
Sathya
Current solution will break down, have to mandate something for the current problem.
Greg
Separate idea of prefix from link id? Routers have a way of selecting different link id.
Hesham
Should be open to having not having shortest prefix, but we should have a default.
Brett
Routers put flag in saysing this is link id, default is shortest prefix, but possible to change in future
Hesham
Flag for link id, what's the point of shortest?
Brett
Routers need to agree.
Mohan
Host isn't involved. Routers need a way to pick this.
SAthya
Say that explicit, separate bit
Hesham
One step, this is link id. Two, can you use to configure addresses
Greg
Some of bits are in prefix info options.
Sathya
One bit may not be sufficient
Suresh
TSLLAO Draft
-------------
Normatively referenced by two documents, which are WG docs
IPv6 chairs want this done in DNA cause IPv6 WG is going into hibernation
Greg will present
(briefly summarizes draft)
Optimistic DAD does not let you use SLLAO:
RFC 2461 has a SLLAO is an option to provide the link-layer address
in order for the receiver to respond without doing NS.
Problem with SLLAO is that it always overrides NC entry in the receiver,
would like to get unicast back to an optimistic address
If we are not sure whether we have arrived on the new link, we need
TSLLAO so that we don't destroy the NCE.
TSLLAO does not destroy NC entry
Implementation in Linux available from Greg
Suresh
RS can't be unicast without option, need to do NS. Necessary to have
this done, IANA allocation
Mohan
Solution all you need is Mac address for repsonse for RA, create NC
entry for packet. Optimistic DAD is written such that create an NC
entry if you don't have it.
Greg
Can send unicast packet back without a Neighbour Cache entry.
Mohan
Does create entry if no entry is there?
Greg
With oDAD, small chance of collision, if there's a collision, we want
operations to be safe for original address owner, advantage if temporary,
won't create or modify an entry (GD: if an entry exists). MAC binding will
be delivered to another destiantion if there is another NC entry.
Suresh: Is there an interest adopt this work ?
WG item - 8 hands
none against
Consensus : Do it on mailing list ?
Greg
Know it's a late agenda item, not trying to shove something through.
Suresh
Should this be in a separate document? 5 hands for
Part of solution document? 2
confirm on list
Vijay: Small extension, should be part of solution.
Brett : Keep it separate because FRD uses it
MILESTONES
-----------
DNA solution protocol by April 2006:
- Interested in the document ?
- Looking for significant comment before that to make that decision ?
Revise milestones- need to come up with realistic dates
Greg presents
Need to set milestones that reflect dates by when documents delivered.
Can submit link layer hints to IESG (passed last call already) next week
Hosts/Routers BCPs
------------------
- can we get it reviewed by Jan. next year?
Would include MLD relocation and other guidance
Willing to review docs? 3 hands
Vijay, Hesham, Bret, Mohan volunteetered to review..
Solutions framework
-------------------
draft expired, anyone interested? (no hands)
Anyone opposed to let it die? (no hands)
Mohan:
Bretts doc doesn't make clear why it was designed a certain way. Is other
document a design doc or a solution framework? Doc was available in Mobike.
Confirm on mailing list
Write framework after? No objection. Will talk to Maragaret.
Solution doc done
-----------------
Interest in helping complete by April 2006? couple hands
Some people are interested.
Significant comment required before March
EoM.
|