[16:08:17] --- TJ has joined
[16:08:23] <TJ> DNA Working Group
[16:08:26] <TJ> Agenda bashing Complete
[16:08:34] <TJ> JinHyeock Choi talking
[16:08:44] <TJ> Clarified term link in the draft
[16:09:42] <TJ> Link & Attachment Point slides - with 3 ARs. But only 2 links (AR2 + 3 share a link)
[16:10:00] <TJ> When MN moves from 2->3, it remains at the same link.
[16:12:16] <TJ> Mentioned that Jim Bound says "DNA in Existing IPv6 Systems" might not be appropriate here, might be moved to a separate draft.
[16:12:33] <TJ> Actual configuration is outside DNA scope
[16:13:56] <TJ> DNA Problems - Difficult to represent link identity, ambiguity of RA information, delay to check reachability of AR
[16:14:52] <TJ> Goals list (6 goals). #1 - dna scheme should detect identity of current link to ascertain the validity of existing IP config. should recognize whether link change has occurred and initiate acquiring new config if necessary.
[16:15:22] <TJ> Goals.. 7-11
[16:16:22] <TJ> Greg Daley - Issue #7 (neighbor discovery)
[16:16:31] <TJ> JH- we can talk about that in the Issues List presentation.
[16:17:05] <TJ> Issue List slide- Jim bound proposes parts of inappropriate analysis to be removed and put in sep. draft
[16:17:20] <TJ> JB suggested to remove the second part of abstract..
[16:17:30] <TJ> (...more proposals from JB, on slide)
[16:18:41] <TJ> Greg Daley says he will put issues list up on the web, so we can discuss and track changes
[16:18:54] <TJ> Any other comments?
[16:19:08] <TJ> Vijay D. - compatibility w/ IPsec and send - nice to have, or don't need it initially?
[16:19:41] <TJ> GD - SEND is like, if you have it you must use it. I like SEND but it's not going to get deployed everywhere. We have to be aware of DNA interactions from SEND to non-SEND solution
[16:19:55] <TJ> Vijay - for us to pick an impl. - how critical is it?
[16:20:17] <TJ> Jari A. - SEND should not break DNA, and vice-versa. I asked about IPsec because...
[16:20:53] <TJ> Erik N - Jim Bound's comment means we can have a goals draft that is much shorter. Mostly just the prob. stmt, plus list of goals, or should we have something that explains a lot more? That's the fundamental question.
[16:21:10] <TJ> The other things are useful IMHO, but might not be in the goals draft.
[16:21:32] <TJ> GD - what do ppl think about that? Should we give an overall motivation, but not details of individual hurdles to tackle?
[16:21:52] <TJ> Does that sound good, or should we have goals and requirements in same document?
[16:22:08] <TJ> #1 - about 12
[16:22:40] <TJ> #2 (more info about challenges/"opportunities" in goals doc?) about 8/9.
[16:23:21] <TJ> We will have to get back to you about proposal for shortened version, and discuss it further on the list.
[16:23:25] <TJ> (from GD)
[16:23:40] <TJ> JH - I would like WG to clearly accept it... (GD - we go to list on that)
[16:23:54] <TJ> JinHyeock - correct spelling
[16:24:16] <TJ> Carl W. not here, we'll skip to L2 Hints draft with Alper
[16:24:28] <TJ> GF - can we get into this without the link trigger and link hint thing?
[16:24:36] <TJ> Alper - What do you mean, that's the whole point?
[16:24:38] <TJ> ...
[16:25:26] <TJ> Alper - Since last IETF, the draft hasn't changed. It got reviews from Bernard Aboba and Greg Daley, but we would like more reviews.
[16:25:54] <TJ> Highlight of comments - both reviewers agreed that link-layer details are a little too much. We agree to reduce them just based on subject
[16:26:11] <TJ> Terminology and associated semantics received a lot of debate, and that's the topic of this presentation.
[16:26:32] <TJ> We want to catalog use for link layer information, but not say how they will be used by DNA -- that's the subject for solution specifications.
[16:27:04] <TJ> Last ietf we proposed use for triggers and hints. Trigger term is extremely overloaded. Hints seems a little too dna solution specific.
[16:27:19] <TJ> New proposal - use terms Link-layer event notification, and Associated information (optional).
[16:27:35] <TJ> LLEN - link up, link down. Just indicate event that took place in the link layer.
[16:27:56] <TJ> Associated with that is optional information, BSSID/SSID, IP address if obtained..
[16:28:07] <TJ> Can be delivered along with the notification.
[16:28:27] <TJ> This is the view as the information passes from the link layer to the network layer, not as it's interpreted by consumer (DNA).
[16:28:51] <TJ> LLEN might look like a hint to the user.
[16:29:20] <TJ> We want to create a draft that will be useful for DNA, but be useable later without binding into semantics of DNA-specific terms
[16:29:29] <TJ> Want feedback on this key issue
[16:29:39] <TJ> GD - Does anyone have opinions about this so far?
[16:30:13] <TJ> Charlie - That's not the only kind of LLEN?
[16:30:23] <TJ> GD - yes... we are avoiding other ones we can't make use of in DNA
[16:30:42] <TJ> TJ - so how's it different than a trigger?
[16:30:56] <TJ> GD - doesn't use trigger word
[16:31:15] <TJ> Alper - Along with PPP establishment, we get an IP address....
[16:31:29] <TJ> Vijay - (too fast)
[16:32:05] <TJ> Talking about IPv6, don't get address . With PDP context you get it
[16:32:45] <TJ> Erik - for IPv6 (PPP) you would want to send up token
[16:33:10] <TJ> Currently draft handles 802.11, cdma2000, GPRS
[16:33:26] <TJ> Erik - by 802.11, doesn't it mean you handle 802.3 (subset)?
[16:33:53] <TJ> GD - Individual link types are useful at this stage. We could extract LLEN later. We are asked to catalog them, but we can't do an exhaustive one.
[16:34:02] <TJ> EN - But I want DNA to work on top of ethernet.
[16:34:30] <TJ> Alper - Current details are specific to 802.11 - weshould have separate text for 802.3
[16:34:47] <TJ> GD - It would be nice to see it as a complete document before we go to making it a WG document?
[16:34:51] <TJ> Vijay - What's the goal?
[16:35:09] <TJ> GD - Little information about LL indications within IETF. We want to use them fairly uniformly for DNA.
[16:35:19] <TJ> Vijay - with these 3 examples, each one is very different
[16:35:34] <TJ> GD - yes but they can send generic IP frames over them once you get to a certain stage in connectivity?
[16:35:50] <TJ> GD - is this useful to make this WG informational when we see the next version of the draft?
[16:36:05] <TJ> GD - JH mentioned that link is another overloaded term.
[16:36:20] <TJ> JinHyeock - presenting on disambiguating meaning of link.
[16:36:44] <TJ> Link / Attachment Point. But People ask me what is a link.
[16:37:00] <TJ> So we have a new term, we should fix it and clearly announce it.
[16:37:14] <TJ> GD - terminology document (indiv submission) where people have been capturing these terms
[16:37:34] <TJ> Has anyone got an idea for what we can use instead of link?
[16:38:02] <TJ> JH - Link segment
[16:38:09] <TJ> Erik - Ethernet segment is different
[16:38:20] <TJ> GD - Wel it's something that isn't bridged.
[16:38:58] <TJ> Erik - if you do mobility by moving ethernet cable, you might move from one switch point to another, or from one hub to another hub..which would be the same segment. So we need to have some scope for using the term as well. We have "point of attachment" as well
[16:39:09] <TJ> You should at least make them be consistent
[16:39:28] <TJ> GD - how about if we match terminology from DNAv4 w.r.t point of attachment. It would replace the term link.
[16:40:32] <TJ> (?) Isn't it about point of presence, not point of attachment? - Darwin
[16:40:49] <TJ> GD - I like that idea, if we consider that IP address is tied to the fixed network and implies a presence.
[16:41:08] <TJ> JH - we have a problem, WG understands. we can fix it later
[16:41:18] <TJ> Samita - why don't we define the term at the beginning of the document?
[16:41:28] <TJ> JH - It doesn't keep people from asking me questions.
[16:41:45] <TJ> GD - We do have a problem and will talk about it on the list leading up to Friday.
[16:41:59] <TJ> We shouldn't get confused between link layer and link-local.
[16:42:30] <TJ> I like the point of presence term.
[16:42:45] <TJ> Please explicitly state if you're confused
[16:42:52] <TJ> (Greg D. and Jari A. raised hands)
[16:43:36] <TJ> GD - that was basically what Carl was going to discuss.
[16:43:41] <TJ> Erik Nordmark now giving presentation on DNA solution framework.
[16:44:06] <TJ> This is what our opinions on a reasonable way to put pieces needed for DNA, and what are the actual pieces needed.
[16:44:16] <TJ> This is the same terminology JH was using a couple minutes ago.
[16:44:33] <TJ> Important to detect whether you're on the same link, or a different link..and then use that to figure out the rest.
[16:44:50] <TJ> You don't seperately change -- if the router's reachable, have the prefixes changed, etc.
[16:45:00] <TJ> If it's the same, you can keep all the information you had before.
[16:45:32] <TJ> We already have the mechanisms in ND and elsewhere, deal with dynamic nature (routers die, prefixes renumber), as long as you're on the same link.
[16:46:15] <TJ> Could be link up notification, router advertisement with surprising prefix, etc.
[16:46:43] <TJ> Receive a RtAdv as soon as possible. You want it to contain enough info so u can determine if you're on the same link, and if you are on a new link, you can configure the things you need immediately.
[16:46:49] <TJ> Draft calls this RA optimized for DNA
[16:47:07] <TJ> Most general is that host, when it receives hint, sends RS as soon as possible
[16:47:19] <TJ> when AP notices new host, it can send most recently cached RA
[16:47:42] <TJ> Determines if it's on the same link before, if no, uses RA to configure new parameters.
[16:48:07] <TJ> So we need notion of what identifies the link. The identity of link could be all global prefixes assigned to link.
[16:48:23] <TJ> If you come somewhere and you have a different set, it's a different link.
[16:49:17] <TJ> It could be a new router advertising a new prefix, but you're on the same link. So in some cases you need multiple RAs to tell with reasonable probability
[16:49:31] <TJ> Vijay - there was some discussion about checking for reachability of router you were using
[16:49:51] <TJ> Erik - doesn't fit in with this view of the world. Single router can have same LL addr on multiple interfaces
[16:51:56] <TJ> Tj - some question about how you really tell it's a different link..
[16:53:43] <TJ> If you have MAC address and layer 3, you can .....
[16:54:08] <TJ> Erik - if you continue using an address on another interface, the response might not come back to you -- it will go to the other interface.
[16:54:39] <TJ> We'll talk more about this on Friday.
[16:55:05] <TJ> You can explore an explicit link ID option so that with modified RA, we can tell if we're on the same link
[16:55:13] <TJ> There's some interaction with things in other WGs like DAD
[16:55:22] <TJ> When you get a hint you might have moved, what should you do with DAD?
[16:55:44] <TJ> Too early to send DAD -- you might be at the same place. But if you have moved and might have a duplicate, you don't want to disrupt owner of that addr.
[16:56:01] <TJ> Treating addresses as tentative after you get a hint might be a good approach.
[16:56:19] <TJ> RS would have Temporary Source Link Local Address O. draft
[16:56:49] <TJ> Work needed - link identifier option, complete prefix list when LI is not available, single RA as quickly as possible, ideally with no delay beyond propogation.
[16:57:06] <TJ> Optionally, ability to have access points at the other end of the "L2" connection
[16:57:44] <TJ> Pieces related to DAD - if you moved you need to make sure you join multicast addr on new link as well. There is an ordering because some multicasts are needed to do DAD
[16:57:47] <TJ> --
[16:58:06] <TJ> GD - Who thought that things were clearer having solution framework presentation.
[16:58:21] <TJ> Who read draft? about 8. Who thinks it's useful (all).
[16:58:42] <TJ> Erik - States certain directions about what solution should look like, at a high level
[16:59:05] <TJ> GD - if you have reviews of that doc, we'll be able to discuss and improve WG's idea of that solution space as well.
[16:59:50] <TJ> Pascal - For link up, seems visitors are able to move, but routers are not able to move.
[17:00:01] <TJ> GD - routers are able to move, because it will appear there will be relative movement.
[17:00:44] <TJ> Pascal - If there is shared media, and some routers may pop up and expose a prefix and then go...I'm not interested in knowing if it's the same line, but rather if the router is still available from the same link.
[17:00:57] <TJ> If the shared media is there, but the router that's there has now gone, it's different
[17:01:17] <TJ> EN - In ND, you have a link and there's a set of prefixes and routers, but there's no relationship between them.
[17:01:39] <TJ> Prefixes don't matter in terms of what router you use for sending packets.
[17:02:11] <TJ> If a router has a prefix only it can route to/from, and another router has prefix it can route to/from, it won't work because of architecture in ND and elsewhere in v6
[17:02:18] <TJ> Pascal - so I can't come in with a router and expose prefix
[17:02:38] <TJ> Erik - fund. problem, when you deploy it, R1 belongs to ISP1 and R2 belongs to ISP2, there's ingress filtering.
[17:02:50] <TJ> So if you use COA1 with R2, packets will be ingress filtered.
[17:05:17] <TJ> Erik - in 802.11, could I run separate VLANs and have that as a mechanism
[17:05:45] <TJ> Vijay - NEMO says that MRs when they're not at home can't send RAs on egress interface. and When they're at home, must send lifetime as 0 so other nodes can't configure
[17:06:42] <TJ> TJ - depends on concept of link -- might not be an advertisement when a router, with certain prefixes, goes off a "link"
[17:06:58] <TJ> pascal - ingress interface of MR ....
[17:07:10] <TJ> Erik - but that's not IPv6 as currently defined in current set of RFCs
[17:07:48] <TJ> (Erik N. shows IPv6 host moving by waving his laptop around)
[17:08:00] <TJ> GD - It's interesting, but may not be relevant
[17:08:25] <TJ> There is some implication that ND infrastructure is there as in RFC2461. Might mean fixed wireless BS, might not.
[17:08:39] <TJ> --- End of session
[17:26:30] --- TJ has left: Disconnected
[17:30:56] --- TJ has joined
[17:42:31] --- TJ has left