Subject: RE: [DNA] Reminder: WG LC on draft-ietf-dna-goals-01.txt is running

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Sep 2004 03:23:20 -0400

I read it and I think it is good.  Good work.
Sorry,
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Pekka Nikander
> Sent: Thursday, September 23, 2004 3:11 AM
> To: Dna
> Subject: [DNA] Reminder: WG LC on draft-ietf-dna-goals-01.txt 
> is running
> 
> This is a reminder that the WG LC on 
> draft-ietf-dna-goals-01.txt is running and ends on next 
> Monday, Sep 27th.  Please do read the draft, and send your 
> comments to the ML, even if it is "I read it and I think it is good".
> 
> http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-01.txt
> 
> --Greg & Pekka, the chairs
> 
>

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Sep 2004 11:33:00 +0300

> http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-01.txt

Overall, I think that the draft is pretty good.  I am sending some
minor edits directly to the authors.

What is more considerable, in my opinion, are the following:

   1. I think we should make clear in the Introduction that
      we are here only dealing with IPv6.  That is clear from
      the context, i.e. our charter, but it should also be
      clearly stated _early_ in the document.  (Or did I just
      miss it?)

   2. I suggest that we add the following paragraph to the
      beginning of Section 3, just after the section title.

    The DNA working group has been chartered to define an improved
    scheme for detecting IPv6 network attachment.  In this section,
    we define the goals that any such solutions should aim to fulfil.

   3. With regard to goal G10, which currently states that ...

>      DNA schemes should take into consideration the case where a host
>      is attached to more than one link at the same time.

     ... should we add "or multiple times to the same link"?

--Pekka Nikander

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 24 Sep 2004 10:28:15 +0900

Pekka

Thanks for kind and helpful comments. 

>       clearly stated _early_ in the document.  (Or did I just

The name of the draft is 'Detecting Network Attachment in 
IPv6 Goals' and I thought that was explicit enough. :-) 

Do you still think we need an additional statement? If so, 
I will add it in the Introduction.  

>     we define the goals that any such solutions should aim to fulfil.

ok. 

>      ... should we add "or multiple times to the same link"?

G10 is about the special case that a host is attached to multiple links 
at the same time and hears different RAs from different links. 

I see few reason to add "or multiple times to the same link". I think 
that's a different case and we may obscure the main issue, 'multiple 
attachment', if we add that.  

Thanks for your kind consideration. 
 
Best Regards

JinHyeock

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 24 Sep 2004 11:01:14 +0300

> I will add it in the Introduction.

Please do.  The change may be as simple as changing "IP"
on the second line of introduction to "IPv6", just as a
reminder.

If you want to put there more, I would suggest also changing
the second last line of introduction:

>    Detecting Network Attachment (DNA).  DNA schemes should be precise,

s/Attachment (DNA)/Attachment for IPv6 (DNA)/

Or, alternatively, to add to the end of introduction:

    This draft considered the DNA procedure only from IPv6 point
    of view, unless otherwise explicitly mentioned.  Hence, the
    term "IP" is to be understood to denote IPv6 by default.

Or something like that.

[My issue #2 removed as we seem to agree on it.]

> attachment', if we add that.

Well, I was thinking about the situation where the host is
connected through several interfaces to the same link.
In some way, this is a special case of a host being connected
through several interfaces to several different links.

I am not sure how to formulate that properly, but IMHO the whole
continuum should be covered by G10.  I don't see it covered
by the other goals.

--Pekka

---

From: JinHyeock Choi <[email-masked]>
Date: Sat, 25 Sep 2004 20:53:46 +0900

Dear Pekka

> on the second line of introduction to "IPv6", just as a

ok. I did this. 
 
>     term "IP" is to be understood to denote IPv6 by default.

I added the above at the end of introduction. 

> continuum should be covered by G10.  I don't see it covered

DNA scheme is run per-interface because some IP configuration, 
such as IPv6 address, is interface specific. 

There arise complexities if an interface of a host is attached to 
multiple links at the same time. For example, the presence of 
a different link identifier doesn't mean that the host is disconnected 
from the current link. 
 
However, when multiple interfaces of a host are connected to the 
same link, it will result in few problem. Each interface may run DNA 
scheme to check for link change and update its IP configuration in 
case of a link change. 

I think the expression 'multiple interfaces' in G10 is confusing. 
I propose to change G 10 as

   G10 Hosts in particular wireless environments may perceive routers
      reachable on different links.  DNA schemes should take into
      consideration the case where a host is attached to more than one
      link at the same time.

Also, as Alper pointed, we'd better explicitly mention that DNA is 
run per-interface. I added the following in Introduction.  

   ..........................of its IP configuration, is called Detecting Network
   Attachment (DNA).

   DNA scheme is run per interface because some IP configuration, such
   as IPv6 address, is interface specific.  When a host has multiple
   interfaces, each interface separately check for link change to verify
   each one's IP configuration.
 
The updated draft is available at 

http://www.diffeo.com/drafts/draft-ietf-dna-goals-02.txt

Best Regards

JinHyeock

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 27 Sep 2004 10:31:00 +0300

> such as IPv6 address, is interface specific.

Well, I do see there some potentiality for using DNA related
information across different interfaces.  Hence, I would _not_
like to mandate DNA to be per-interface.

For example, if a host has earlier been connected twice to the
same link through two different interfaces, and then it detects
that one of the interfaces has undergone a link change, IMHO that
is a strong indication that there may have been a link change
at the other interface, too.

<snip>

> scheme to check for link change and update its IP configuration in

I agree that there shouldn't be that many new *problems* related
to DNA.  However, I think it may be possible to use some DNA
related information for *optimising* behaviour.  We have to
remember that DNA is mostly about optimisation, anyway.

>       consideration the case where a host is attached to more than one

This is better.

>    each one's IP configuration.

As I wrote above, I don't agree with this.  I think this is unnecessary
in the goals document.  I don't think we should include it.
OTOH, if other's in the WG think otherwise, I won't insist.

--Pekka

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 27 Sep 2004 19:27:18 +0900

Pekka

We are in a disagreement. 

> at the other interface, too.

'mandate' may be a too strong a word but, I think, by default DNA 
will be run per-interface. Each interface should detect the identity 
of its currently attached link for itself. 

This doesn't mean each interface can't share DNA related information
among themselves. 

Even in the above example, the fact that one interface has undergone 
a link change doesn't automatically confirm that the other interface 
also has undergone a link change. As you wrote, though strong, that 
is just a hint, so the other interface needs to run DNA scheme to 
check for link change for itself.   

Moreover, in case a host has multiple interfaces, it's more likely 
each interface is of different link-layer technology. For example, 
a host would have a 802.11 interface and 802.16 interface rather than 
two 802.11 interfaces. In that case, what happened at one interface 
doesn't tell much about the status of the other interface.  

> remember that DNA is mostly about optimisation, anyway.

I agree that they may be the optimization possibility you pointed. 
However, it's not clear to me how we will reflect that in Goals.   

ok. 

> OTOH, if other's in the WG think otherwise, I won't insist.

Let me summarize my thoughts. 

In case there are multiple interfaces in a host, each interface should 
separately detect the identity of the currently attached link for itself. 

Do you disagree with this? If so, we are in a serious disagreement 
and would better find a way to resolve this. 

Best Regards

JinHyeock

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 27 Sep 2004 13:36:58 +0300

> We are in a disagreement.

Somewhat, yes.  But I don't think the disagreement is that bad.  :-)

<snip>

> and would better find a way to resolve this.

Well, I don't really disagree with you at that point.  However,
IMHO we would needlessly limit ourselves if we, in the goals
document, state that DNA schemes are (always) run per interface.
I would easily agree that they are "typically" or even "almost
always" run per interface.  However, there are cases where that
may not hold.  Hence my concern.

But I'd like to hear other opinions on this.

--Pekka

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 27 Sep 2004 20:24:07 +0900

Pekka

> Somewhat, yes.  But I don't think the disagreement is that bad.  :-)

Glad and relieved to hear that. :-)
 
> may not hold.  Hence my concern.

I see your point. Kindly tell me your suggestion how we will 
resove this. Would you like us to remove the paragraphs?  
I can live with it but Alper may have a different opinion. If so, 
I will try to rephrase the parts to be acceptable to both of you.
 
> But I'd like to hear other opinions on this.
 
Me too. 

Best Regards

JinHyeock

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Sep 2004 04:34:59 -0700

IMO, DNA needs to be per interface. and ofcourse information could
be shared between interfaces.

Vijay

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 27 Sep 2004 16:00:43 +0300

> I will try to rephrase the parts to be acceptable to both of you.

To me it is OK enough if we add the word "typically", and simplify
the paragraph somewhat.

    DNA schemes are typically run per interface.  When a host has
    multiple interfaces, the host separately checks for link changes
    on each interface.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Sep 2004 09:43:51 -0700

> at the other interface, too.

Pekka,
do you have a concrete example where this makes sense?

I don't have a problem relaxing the wording in the goals draft to not 
accidentically preclude optimizations which share information between 
interfaces, but I don't understand your example above.

   Erik

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 28 Sep 2004 12:23:44 +0300

Erik

> do you have a concrete example where this makes sense?

The specific example, though simplistic, that I've had in my mind
is my home setting with my laptop.  I have a bridged Ethernet and
WLAN.  When my laptop notices that I've disconnected it from the
Ethernet, I may have just moving it around in our house, and it
is still connected to the same link through WLAN.  On the other
hand, I may have suspended it and moved it e.g. to the office,
in which case it is now attached to a different WLAN.

Another example that I could imagine is a large operator network
that from an IPv6 point of view acts as a single, large "LAN"
or NBMA link.  (I know one operator that has plans like that.)
The operator might offer different radio access technologies to
access that "large LAN".  When one radio interface undergoes a
change, it may make sense to quickly verify whether the other
interfaces still are connected to the "large LAN".

In general, if two interfaces are connected to the same subnet,
and one of the undergoes a link change, it often makes sense to
check if the other one has also went through a link change.

> I don't have a problem relaxing the wording in the goals draft
> to not accidentically preclude optimizations which share
> information between interfaces, but I don't understand your
> example above.

I was mostly objecting the notion that we should keep DNA on
separate interfaces _completely_ independent.  To me, it looks
like that there are cases when they are not.  I am oblivious
how to handle this, through link hints, relaxing the language
in the goals draft, or whatever.

--Pekka

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 28 Sep 2004 22:14:16 +0900

Pekka

> check if the other one has also went through a link change.

I think the relation between a link change in one interface and 
a link change in another interface is similar to the relation between 
a link change in IP layer and a link-layer change in MAC layer. 
When a host changes its link-layer connection, it make sense to 
check whether a link change also has happened. However, 
a link-layer change doesn't automatically imply a link change, 
so IP layer can't solely depend on it and (typically) checks for 
link change for itself. So I guess their relationship is neither 
completely dependent nor completely independent, but, in between, 
interdependent. (It's as if I talk about the man-woman relationship. :-))

> in the goals draft, or whatever.

It's not my intention to argue that we should keep DNA on 
separate interface _completely_ independent. 

It seems that we are in agreement that 

1. DNA schemes are typically run per interface.
2. When a host has multiple interfaces, the DNA related 
   informations can be shared between interfaces for the 
   better performance. DNA on separate interfaces need 
   not be completely independent. 

I think we have reached a common ground and would like to 
adopt your rewriting to resolve this issue. 

Kindly give your opinion on it. 

Best Regards

JinHyeock 

P.S.
This is 15th August, the greatest Korean holiday, HanGaWi. From 
earlier days, we celebrated good harvest with families under full
moon. Happy HanGaWi to all. :-)

---

From: Alper Yegin <[email-masked]>
Date: Tue, 28 Sep 2004 15:26:55 -0700

> > separate interfaces _completely_ independent.  

That was not my intention when I said "DNA scheme is run per-interface".
What I meant was the result that is produced by DNA scheme (e.g.,
whether IP reconfig is necessary) must have a target interface. It
cannot be per host, which may have multiple interfaces. Getting to that
result may use input from other network interfaces, and even non-network
interfaces (e.g., GPS), that's fine. 

The current text refers to "host" changing links. Actually, it is a
network interface on the host that is changing links. A dual-interfaced
host may disconnect eth0 from link_x connect eth1 to link_x. Host is
still connected to the same link, hence no "link change per-host", yet
the IP configurations on the eth0 and eth1 has to change. 

Maybe we should say "DNA scheme is run per-interface. While the
detection is performed for an interface, the DNA scheme may take hints
from other interfaces when useful. "

Alper

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Sep 2004 16:07:12 -0700

> in which case it is now attached to a different WLAN.

Yes, but your neighborhood ISP might provide metro Ethernet including
your house and your office. Taking GPRS and 802.11 as the interfaces 
illustrates this better - detecting attachment to a new link on one of
them doesn't say much about the other link.

In your example the more likely hint is that the laptop has been 
suspeded for some time, hence reverifying things makes a lot of sense.

> interfaces still are connected to the "large LAN".

But I still don't see why there would be a correlation since the 
technologies and operators might be different.

> check if the other one has also went through a link change.

I still don't understanding which assumption you are making.

A counter example would be that I have wired Ethernet and 802.11 in the 
house. Just because I unplug from the wire to walk around, or untangle 
some other wires on the floor in my office, doesn't mean I'm likely
to have changed the 802.11 AP. In any case, if I change the 802.11 AP
the device driver will associate with another AP hence can provide a 
hint to DNA.

> in the goals draft, or whatever.

Yes, at least across interfaces with compatible technology it makes 
sense to share retained information. Imagine a host which remembers DNA 
info (prefixes, default routers) and binds them with some L2 key (the 
MAC address of the Ethernet bridge or AP).
If the host has multiple Ethernets interfaces (or multiple 802.11 
interfaces) it should be able to find this cached information and make 
use of it; we shouldn't require that the same Ethernet wire be plugged 
in as the last time.

    Erik

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 30 Sep 2004 14:52:04 +0300

>    not be completely independent.

Agreed.

>    multiple interfaces, the host separately checks for link changes

Sounds good enough.  I wish I could suggest a slightly different
tone, but I don't have the energy right now.  Hence, this is good.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 30 Sep 2004 14:54:53 +0300

Erik,

> I still don't understanding which assumption you are making.

I guess I wasn't clear enough in my own thinking.  I was mostly
motivated by the fear of painting ourselves somehow into a corner.

> Yes, at least across interfaces with compatible technology
> it makes sense to share retained information. Imagine a host
> which remembers DNA info (prefixes, default routers) and binds
> them with some L2 key (the MAC address of the Ethernet bridge or
> AP).  If the host has multiple Ethernets interfaces (or multiple
> 802.11 interfaces) it should be able to find this cached
> information and make use of it; we shouldn't require that
> the same Ethernet wire be plugged in as the last time.

Good example, thanks!

--Pekka

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 01 Oct 2004 00:59:19 +0900

> >    not be completely independent.

Glad to hear that. 

> tone, but I don't have the energy right now.  Hence, this is good.

I am glad that we have found a common ground acceptable to both 
parties without much crawling and wish every contention to be 
resolved in this manner. Thanks for your trouble and I hope it's not 
me who wore you down. For me, sometimes, editing is the choice 
between the unpalatable and the unbearable. :-) 

JinHyeock