Subject: Re: [DNA] Model: how to treat "link down" events

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Feb 2006 16:31:02 -0800

Thomas Narten wrote:
> In thinking through this, one thing that is not clear to me is what
> the model is for what to do when a "link down" event takes place. This
> is actually important to understand as it plays into how to handle
> "link up" events.

This discussion might be interesting, but I'm not sure it is critical or 
even relevant to DNS, since we've designed DNA to only operate using 
'link up' event notifications i.e., there is no dependency on any 'link 
down' event notifications.

> RFC 2461/2462 defines the IPv6 behavior for configuring a link with
> IPv6 information such as addresses, MTU, on-link prefixes, etc.  When
> a link goes down, conceptually one disables the interface and discards
> all associated config info. 

FWIW I take exception to this interpretation. There is nothing in 
2461/62 that leads me to believe this was the intent.

In fact, the default timers in the RFCs are quite long (90 minutes for 
default routers, and 7 days until an address becomes deprecated - 30 
days to become invalid.)
I don't remember exactly how we picked those values, but I have vague 
recollections that we didn't want the IPv6 addresses to accidentally 
disappear just because the router that advertises the prefix disappears 
for a few days. So I think the intent when 2461/62 was written was to 
err on the side of stability of the addresses.
Your assertion that the specifications should be interpreted as 
discarding everything on a 'link down' event doesn't match that presumed 
desire for stability.

> Q: what is a good model for what to do with the config information
> assocated with an interface that is going down? In some cases (e.g.,
> administrative shutdown of an interface) returning hard errors to
> upper-layer protocols is probably OK. But for wireless hiccups, it may
> not be.  And if I unplug a wired ethernet from the jack, should that
> automatically cause all connections using the address on that
> interface to fail? Not clear. There are certainly times when I wish
> that didn't happen...

I can recommend an Open Source OS and IPv6 stack that doesn't have that 
problem ;-)

> Proposal:
> 
> There are two types of errors that can be returned upon sending a
> packet:
> 
> hard error: means a failure of a type for which retrying is likely to
>             result in the same error, and upper layer protocols are OK
>             giving up.
> 
> soft error: a temporary failure occured, but retrying a short time
>             later may result in a different result. I would put "ICMP
>             dest unreachables" into this category.
> 
> 
> When a link goes down (i.e., via a "link down" event), soft errors
> should be returned when a) sending through the interface, or b) if
> using addresses associated with that interface. Soft errors should be
> returned from some short time. After (say) 2 minutes, hard errors can
> be returned.
> 
> Does this make sense?

It might make sense. But I don't see how defining these things more 
carefully, and making the above recommendations, would have any impact 
on how we specify the behavior of the DNA.

We can't rely on timely 'link down' events for DNA, hence it makes sense 
to only rely on 'link up' events, which is what CPL and the DNA solution do.

    Erik

---

From: [email-masked]
Date: Wed, 01 Feb 2006 17:37:50 -0800

Erik,

Is the following scenario possible ?

1) Host receives a link down event. Does not do anything.
2) Host attaches to the new link. Link UP event happens
   slightly late or the event has not propagated completely
   through the system. Meanwhile you are able to send and
   receive packets. This is not good because you are not
   in the optimistic state yet and you are on the new link.

-mohan
    
>This discussion might be interesting, but I'm not sure it is 
>critical or even relevant to DNS, since we've designed DNA to 
>only operate using 'link up' event notifications i.e., there 
>is no dependency on any 'link down' event notifications.
>
>In fact, the default timers in the RFCs are quite long (90 
>minutes for default routers, and 7 days until an address 
>becomes deprecated - 30 days to become invalid.) I don't 
>remember exactly how we picked those values, but I have vague 
>recollections that we didn't want the IPv6 addresses to 
>accidentally disappear just because the router that advertises 
>the prefix disappears for a few days. So I think the intent 
>when 2461/62 was written was to err on the side of stability 
>of the addresses.
>Your assertion that the specifications should be interpreted 
>as discarding everything on a 'link down' event doesn't match 
>that presumed desire for stability.
>
>I can recommend an Open Source OS and IPv6 stack that doesn't 
>have that problem ;-)
>
>> Proposal:
>> 
>It might make sense. But I don't see how defining these things 
>more carefully, and making the above recommendations, would 
>have any impact on how we specify the behavior of the DNA.
>
>We can't rely on timely 'link down' events for DNA, hence it 
>makes sense to only rely on 'link up' events, which is what 
>CPL and the DNA solution do.
>
>    Erik
>
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 01 Feb 2006 20:19:22 -0500

> down' event notifications.

Right. I just started thinking about it as I was trying to understand
what information is associated with an interface when one gets a 'link
up' (i.e., there are some unstated assumptions being made in the DNA
drafts I think, and I'm trying to flesh them out). It wasn't
immediately obvious that (by default) any information would be
associated with an interface.

> 2461/62 that leads me to believe this was the intent.

Fair enough. I'm definitely not saying that I think this is what
should be doing.

> In fact, the default timers in the RFCs are quite long (90 minutes
> for default routers, and 7 days until an address becomes deprecated
> - 30 days to become invalid.)  I don't remember exactly how we
> picked those values, but I have vague recollections that we didn't
> want the IPv6 addresses to accidentally disappear just because the
> router that advertises the prefix disappears for a few days.

Ah.. but a router going away (with an apparently still working link)
strikes me as different than a link that goes down -- and for which we
get an explicit indication from the LL that the link has gone
down. Note: maybe ten years ago when we were doing the spec twisted
pair ethernet was a lot less ubiquitous and the notion that one got
'link down' indications from the interface was a lot less
common. Wireless was still a dream... :-)

> So I think the intent when 2461/62 was written was to err on the
> side of stability of the addresses.  Your assertion that the
> specifications should be interpreted as discarding everything on a
> 'link down' event doesn't match that presumed desire for stability.

I don't mean to assert that. I do think that we (the community as a
whole) didn't think about this part in a lot of detail.

> on how we specify the behavior of the DNA.

What I'm trying to get at is: what assumption can be made about the
configuration information that is already associated with an interface
(i.e., from 2461/2426) at the time a 'link up' event takes place?

I guess the obvious model is that whatever IP configuraiton
information  was associated with the interface before the link up
(subject to any lifetime considerations) is assumed to still be
associated with the interface.

But think about this just from a 2461/2462 perspective (i.e., before
we started thinking about DNA). What would happen in practice in a
pre-DNA world?  Suppose an RA is received on an interface, but it
indicates a new prefix that one has never heard of, and it doesn't
include any prefixes currently associated with the
interface. Shouldn't the old information be thrown away (since we
might be at a new link). It needs to be discarded at some point, not
because it has expired, but because it doesn't apply to the current
link anymore. some of that informaitn will stay around for a very long
time if one only looked at Lifetimes. [I don't recall any of this
being discussed in 2461/2462.]

It seems to me that some assumptions have to be made in order to
define what it is that DNA is supposed to do, or, what state it
assumes as it gets invoked.

> We can't rely on timely 'link down' events for DNA, hence it makes
> sense to only rely on 'link up' events, which is what CPL and the
> DNA solution do.

Agreed that we can't _rely_ on them. But there are presumably cases
where they will occur. How should they be handled? Just note them ,
but more-or-less silently ignore them?

Thomas

---

From: [email-masked]
Date: Wed, 01 Feb 2006 20:11:01 -0800

>We can't rely on timely 'link down' events for DNA, hence it makes
sense to only rely on 'link up'
>events, which is what CPL and the DNA solution do.
>
>    Erik

If timely link down events were available (say from IEEE 802.21), would
that help things?

Best Regards,
Michael
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Erik
Nordmark
Sent: Wednesday, February 01, 2006 4:31 PM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: [DNA] Model: how to treat "link down" events

In fact, the default timers in the RFCs are quite long (90 minutes for
default routers, and 7 days until an address becomes deprecated - 30
days to become invalid.) I don't remember exactly how we picked those
values, but I have vague recollections that we didn't want the IPv6
addresses to accidentally disappear just because the router that
advertises the prefix disappears for a few days. So I think the intent
when 2461/62 was written was to err on the side of stability of the
addresses.
Your assertion that the specifications should be interpreted as
discarding everything on a 'link down' event doesn't match that presumed
desire for stability.

We can't rely on timely 'link down' events for DNA, hence it makes sense
to only rely on 'link up' events, which is what CPL and the DNA solution
do.

    Erik

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 02 Feb 2006 18:48:33 +0900

Dear Michael

> If timely link down events were available (say from IEEE 802.21), would

Not so much, in my opinion.

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 02 Feb 2006 18:47:35 +0900

Dear Mohan

>   receive packets.

I have difficulty understanding above. How can the host send/ receive
packets when it is attached to a new link in which it has no IP
configuration information such as IP address?

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 02 Feb 2006 18:48:17 +0900

Thomas

> Note: maybe ten years ago when we were doing the spec twisted

Not anymore, I am happy to say. :-)

> associated with the interface.

Agree. However the host would better keep from using the information
(such as sending a packet with the existing IP address as a source
address) until DNA procedure determines that it really remains at the
same link.

> might be at a new link).

This is the question we tried to answer with CPL.

When the host is sure that it knows all the prefixes on the link (i.e.
having the Complete Prefix List), it can throw away the old
information because a new prefix implies a new link. If it is not so
sure, it would better take some time before make a decision to throw
away.

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 02 Feb 2006 18:46:33 +0900

Dear Thomas

I approach this in view point of how to manage IP configuration
information (such as IP address) upon link down event.

In short, I think that
In case only link down event happens (without subsequent link up
event), it's ok for a host to keep assigning the cached config
information to the interface.

Whereas in case link up event follows link down event, the host needs
to perform DNA to check for link change. If a link change has
happened, the host should discard the cached config information. If
not, it can keep using the existing information.

Kindly see the inline comments.

> all associated config info. However, this has the negative side-effect
> of causing upper-layer protocols using those addresses to possibly get
> "hard errors" and terminate connections when sending
> traffic. [Actually, is this true, or are things more nuanced, i.e.,
> does one get errors when sending but here is no route, or when sending
> but using an invalid source address, or???] In the common case where a
> link goes away for a few seconds and then comes back up connected to
> the same link (with the same associated config information) this is
> obviously undesirable.
>

I guess we'd better treat this problem in relationship with link up event.

First link down event occurs.
- Upon this event, I see few harm if a host keeps the existing config
information in anticipation of  link recovery till the lifetime
expires. (Link-layer connection is broken, so communication is not
possible anyway.)

Second link up event occurs.
- At this stage, the host can't be sure it still remains at the same
link or not. So it starts DNA procedure.
- It can still maintain the existing config information but keeps from
using it (such as using the existing IP address as a source address).

Third DNA completes
- At this stage, the host can determine what to do with its existing
config information, to discard or to keep using.

* The only problem may be the case that a host is detached from a link
for quite a long while, then reattach itself to the same link.
Because, during the host's absence from the link, none protected the
host's IP address (w.r.t. DAD), the host can't be sure that it's IP
address is still unique. It may need to perform DAD once more.

* Also I had a small experiment. I took the ethernet jack from my
laptop and put it again some time later. It kept using the same IP
address. :-)

> One possible model:
>
>  - some types of "link down" events are absolute (like an
>    administrative shutdown)
>
>  - some "link down" down events should be treated suspiciously (e.g.,
>    wireless) and should not result in (immediate) error to
>    upper-layer protocols.
>
>  - by default, one should not return hard errors immediately (in
>    anticipation of the link coming back up) but one can do so after
>    some timeout. So, should we say after N minutes, an interface is
>    really dead?
>
>  - can we provide guidelines for what to do in general?
>
> Proposal:
>

I think the above applies when there is no subsequent link up event.
But, for example, if a host is re-attached to a new link within (say)
2 mins (and recognizes a link change), I guess hard error needs to be
returned.

> Does this make sense?
>
> Note: in terms of DNA, when a "link up" event takes place, I would
> imagine that we could distinguish between a "link up" event that
> happens within (say) 2 minutes of a "link down" or after a much longer
> time period, possibly treating the behavior somewhat differently.

'IP address' may be treated differently according to the length of
detachment time. For example, we may make a rule as below.

When a host is detached from a link less than 2 mins and reattaches
itself to the same link, it can immediately use its IP address without
DAD. On the other hand, if a host is detached from a link more than 2
mins, it should perform DAD before using its IP address even when it
reattaches itself to the same link.

Best Regards

JinHyeock

---

From: [email-masked]
Date: Thu, 02 Feb 2006 10:37:11 -0800

>2461/62 that leads me to believe this was the intent.
I agree with this. But i found this in 2462bis.

   A node forms a link-local address whenever an interface becomes
   enabled.  An interface may become enabled after any of the following
   events:

   -  The interface attaches to a link for the first time.  This
      includes the case where the attached link is dynamically changed
      due to a change of the access point of wireless networks.

What does it mean to form a new link-local address when you switch
Access Points ? Does it mean throw away the old link-local address ?
Only the link-local address ? I don't remember the discussion that lead
to the above text. It sure does not say "throw away the old info".

-mohan

---

From: [email-masked]
Date: Thu, 02 Feb 2006 10:50:37 -0800

>I have difficulty understanding above. How can the host send/ 
>receive packets when it is attached to a new link in which it 
>has no IP configuration information such as IP address?
>
When a host attaches to the new link, as per the solution
document, the host sends a RS with TSLLAO option to determine
whether it has changed links or not. The source address of the
RS is a link-local address which was previously in preferred
state but now in optimistic state. If it knows that it moved
to a new link, it discards old information and starts
configuring new addresses from the RA. In the above scenario,
as the host has not seen the Link UP trigger yet, it does
not send the RS, does not set the addresses to Optimistic
and just sitting there thinking it is old link. If another
node attached to the same link with the same link-local
address, both the nodes will respond to the NS and override
flag will not be cleared in both of the NAs.
Eventually right things will happen, when the RS goes out,
but in a small window, there can be this problem. This is
not a opti-DAD problem, because you send NA with override
flag cleared when you are in optimistic mode.

It looked to me that if you go to optimistic on seeing
Link Down (i understand that it is not reliable etc..), then
this problem (assuming it is one) may not happen.

-mohan

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 16:42:50 -0800

> even relevant to DNS, since we've designed DNA to only operate using 

Oops. s/DNS/DNA/

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 17:28:09 -0800

> to the above text. It sure does not say "throw away the old info".

It doesn't make much sense, since the link-local address (for most 
IPv6-over-foo specifications) is formed from some hardware IEEE address, 
thus forming it again would result in generating the same link local 
address.

There is a legitimate question of when a host should redo (optimistic) 
DAD, but that is something which makes sense specifying in the DNA 
document(s) and not in 2462bis.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 17:17:36 -0800

> If timely link down events were available (say from IEEE 802.21), would

I don't think they would help with DNA, since DNA on a single-homed host 
can't do much useful from knowing that the network disappeared. The 
upper layers, like application protocols, could stop waiting for the 
network to respond, but perhaps they should be patient and wait for it 
to come back.

For multihomed hosts, in particular those having protocols like MOBIKE 
or SHIM6, getting a timely link down event helps to have it quickly 
switch to using an alternate network interface.

    Erik

---

From: [email-masked]
Date: Thu, 02 Feb 2006 17:56:16 -0800

>We can't come up with any reliable DNA procedure in such a 
>case. One would more or less end up ignoring the 'link up' 
>event and just rely on the content of the RAs as suggested in 
>5 in CPL; but as stated that approach isn't robust; if a host 
>moves too often it can conclude that the union of prefixes 
>from multiple links are in fact the prefixes assigned to a single link.
>
>And the two authors of CPL and Thomas agree that we can drop 
>that section.
>
>So for a reliably DNA we do have to assume that the link up 
>event notifications are delivered in order relative to packets 
>arriving from the network interface.
>
The above case may not be an abnormal case. The "Link UP" event
needs to be processed even though it has been generated by
the lower layer. This may take some time. It is not atomic in
the sense that when the event happens,  no packets are allowed
till the event is processed. Do you think that this case is
a pathological case ?

>Note that draft-pentland-dna-protocol* can do slightly (as in 
>epsilon) better than CPL, since the DNA procedure can tie the 
>received RA to the RS one way or another. But this doesn't 
>help tell whether the prefixes received in periodic, 
>unsolicited RAs belong to one link or another when there is no 
>'link up' event notification.
>
But see my other mail. My concern is what happens before the
RS is sent and you are not receiving any RAs but some
neighbor solicitations on the new link.

-mohan

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 18:02:19 -0800

> associated with an interface.

OK. Since you've read it with a fresh pair of eyes you can help us make 
those assumptions explicit.

> common. Wireless was still a dream... :-)

I think we worried more about routers going away (perhaps they were 
flakier back then).

But with wireless loosing the hosts attachment to the link (which isn't 
really "the link" going down) is a lot more common when you're at the 
edge of the coverage area or there is too much interference.

> whole) didn't think about this part in a lot of detail.

I agree that the community didn't think that much about it, even if we 
had some reason that we picked 7/30 days for the default preferred and 
valid lifetimes.

> associated with the interface.

Yes.

> being discussed in 2461/2462.]

But here is where the flexibility of 2461/62 comes to bit us.
The RFCs don't require that the routers on the link advertise the same 
set of prefixes, and they don't even require that a single router put 
all its prefixes in a single RA. (The latter part of the flexibility is 
necessary should a router have more prefixes to advertise than fits in a 
single 1280 byte RA.)

Thus a RA might appear with a previously unknown prefix even though we 
are still attached to the same link.
It might not be very common in the IPv6 deployment we have today, 
because I suspect there are relatively few prefixes for each link and 
that all the routers advertise the same prefixes. (But in the context of 
Nemo folks have discussed having different routers advertise different 
prefixes, which actually doesn't make much sense to me.)

If we require a 'link up' event (and delivered in order with received 
packets as Mohan pointed out), then in what case could this generality 
bite us when the host didn't move to a new link:
1. Host receives link-up event. Sends a RS.
2. The first RA it receives is one that has a prefix that it hasn't seen 
in a RA on the link before.

The probability of this RA being an unsolicited, periodic RA is quite 
small, since the solicited responses will all arrive within at worst 3.5 
seconds. (.5 second random delay, plus if there are lots of hosts 
sending RSes, then the rate limit of at most one multicast RA every 3 
seconds will kick in). Given that the default period RA timer is 30 
minutes its unlikely that it will fire within that 3.5 second period.

So most likely the host will receive a solicited RA.
And most likely that RA will include prefixes that it has heard before.

But the Internet is a complex, and as a result a flaky place. The 
wireless physics makes things less than perfect. Do we really want to 
add more flakiness by assuming that the first RA is always a complete one?

We do need a change to the router behavior in any case to avoid waiting 
for .5 to 3.5 seconds for a RA. Can't we make CPL not introduce new 
sources of flakiness and have the DNA solution (like the ones we have on 
the table) also make sure the host can always tell for sure from a 
single RA whether it has moved or not?

> but more-or-less silently ignore them?

If we require reliable and ordered (with respect to received packets) 
'link up' event notifications, then DNA doesn't need to look at 'link 
down' since they don't carry any useful information that helps us tell 
whether a future 'link up' will imply moving to a different link or 
staying at a different link.

But protocols like MOBIKE and SHIM6 want to pay attention to a 'link 
down' event.

    Erik

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 03 Feb 2006 11:03:48 +0900

Dear Mohan

Thanks for your kind clarification which made me see the light. :-)

> this problem (assuming it is one) may not happen.

Now I understand, thanks. :-) I think that even after seeing Link Down
even, a host can maintain the current IP configuration information.
But the host would better keep from using it (it switches to a kind of
optimistic mode) until DNA procedure affirms that the host really is
attached to the same link.

Best Regards

JinHyeock

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 18:27:22 -0800

> till the event is processed. Do you think that this case is

My simple model assumes the whole IP layer (including Neighbor Discovery 
and DNA) is a single event-driven loop, i.e. the link up event and 
receives NS packets would be processed in the order the device driver 
passes them up.

If the implementation separates things, e.g., handling NS in the kernel 
and the 'link up' events in a daemon, then it needs to take care to 
preserve the ordering in this case.

I don't think using 'link down' helps here, because we have the common 
case of AP handover, where the change from using one AP to another is 
more or less instantaneous. Even if we mandate a 'link down' in that 
case, it would be immediately be followed by a 'link up', thus a split 
implementation would still need to handle the ordering issue.

I suspect it's not that hard to have a split implementation do the right 
thing. The 'link up' event can be used by the kernel to immediately set 
the optimistic DAD state, and then pass the event to the daemon that 
does DNA/RS/RA. That daemon will later tell the kernel when to turn off 
the optimistic state.

But it sure is worth-while to list this as an implementation 
consideration, in addition to making a clear statement about the 
ordering/atomic behavior of the host as a whole for this issue.

Do we put that in CPL or in draft-pentland? They both need the same thing.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 17:14:49 -0800

>    in the optimistic state yet and you are on the new link.

We can't come up with any reliable DNA procedure in such a case. One 
would more or less end up ignoring the 'link up' event and just rely on 
the content of the RAs as suggested in 5 in CPL; but as stated that 
approach isn't robust; if a host moves too often it can conclude that 
the union of prefixes from multiple links are in fact the prefixes 
assigned to a single link.

And the two authors of CPL and Thomas agree that we can drop that section.

So for a reliably DNA we do have to assume that the link up event 
notifications are delivered in order relative to packets arriving from 
the network interface.

Note that draft-pentland-dna-protocol* can do slightly (as in epsilon) 
better than CPL, since the DNA procedure can tie the received RA to the 
RS one way or another. But this doesn't help tell whether the prefixes 
received in periodic, unsolicited RAs belong to one link or another when 
there is no 'link up' event notification.

    Erik

---

From: [email-masked]
Date: Fri, 03 Feb 2006 09:38:45 -0800

>
>> The above case may not be an abnormal case. The "Link UP" 
>event needs 
>> to be processed even though it has been generated by the 
>lower layer. 
>> This may take some time. It is not atomic in the sense that when the 
>> event happens,  no packets are allowed till the event is 
>processed. Do 
>> you think that this case is a pathological case ?
>
>My simple model assumes the whole IP layer (including Neighbor 
>Discovery and DNA) is a single event-driven loop, i.e. the 
>link up event and receives NS packets would be processed in 
>the order the device driver passes them up.
>
>If the implementation separates things, e.g., handling NS in 
>the kernel and the 'link up' events in a daemon, then it needs 
>to take care to preserve the ordering in this case.
>
>I don't think using 'link down' helps here, because we have 
>the common case of AP handover, where the change from using 
>one AP to another is more or less instantaneous. Even if we 
>mandate a 'link down' in that case, it would be immediately be 
>followed by a 'link up', thus a split implementation would 
>still need to handle the ordering issue.
>

Yes, the ordering issue is just not between the control events
but with respect to the packets received. I agree that setting
optimistic on receiving Link down will not work because even
that is not atomic.

>I suspect it's not that hard to have a split implementation do 
>the right thing. The 'link up' event can be used by the kernel 
>to immediately set the optimistic DAD state, and then pass the 
>event to the daemon that does DNA/RS/RA. That daemon will 
>later tell the kernel when to turn off the optimistic state.
>
I agree that this is the only way it can work for maintaining the
ordering. 

>consideration, in addition to making a clear statement about 
>the ordering/atomic behavior of the host as a whole for this issue.
>
Yes. Depending on the OS implementations, this is a very important
issue to consider.

>Do we put that in CPL or in draft-pentland? They both need the 
Agreed.

thanks
mohan

---

From: Greg Daley <[email-masked]>
Date: Fri, 03 Feb 2006 14:12:27 -0500

Hi Erik,

Erik Nordmark wrote:
[cut]
> Do we put that in CPL or in draft-pentland? They both need the

I think that the draft-ietf-dna-hosts already mentions some
considerations about DAD optimistic behaviour.   Perhaps
it should go there.

Thomas' question about whether CPL and Hosts are really
separate still remains, although I think at an earlier
time, the WG consensus was to keep the drafts separate.

If they're separate, we may wish to send them paired
to the IESG like SEND and CGA (RFC3971 and RFC3972).
This could make some sense, as CGA is mechanism and
SEND a system, like CPL is a mechanism, and DNA is
a system.

Opinions are welcome on this issue.

Greg

---

From: Thomas Narten <[email-masked]>
Date: Tue, 07 Feb 2006 12:23:18 -0500

> time, the WG consensus was to keep the drafts separate.

Why? And what is the benefit of keeping them separate?

I just read through the dna-hosts document, and I can't quite figure
out what its trying to do (relative to cpl). On the one hand, it (at a
high-level) describes some issues with DNA, etc., without making
specific recommendations. On the other hand, in some areas, it
includes some fairly specific SHOULD/MAY type terminology and makes
recommendations about adding random delays and such. I.e, much more
like a spec.

I strongly believe that we do not want two different documents on the
standards track making recommmendations on what a host should do for
DNA (to work with unmodified routers). All recommendations should be
in one document, and the recommendatoin we want hosts to implement
should be clear.

As it stands now, there is some overlap beween the two documents, and
there is some stuff covered in hosts that (if it needs covering)
should probably be moved to cpl.

So if there is  some reasoning for why we need two documents (and how
the content of those two documents complements, but does not overlap
with each other), I'd like to hear it.

Thomas

---

From: Greg Daley <[email-masked]>
Date: Tue, 07 Feb 2006 14:54:53 -0500

Dear Thomas,

> Why? And what is the benefit of keeping them separate?

Personally, I've no objection to combining them,
although there was an intention at the time (as I
recall, -hosts and -routers were combined at the time,
and there was even more text in them).

We need to check that it's a good match if there's
to be merger (this is what we're doing now).

We'd want to see what the WG says, so I encourage people
to show an opinion.

> recommendations about adding random delays and such. I.e, much more

Hosts does include a lot of the background and motivation
which was omitted from CPL,  for example information pertaining
to points 4) and 5) mentioned in your review of the document.

Where existing recommendations were superceded by the CPL algorithm,
the hosts document was reorganized to refer to the algorithm,
without duplicating it (except for a stub in section 4.2.2 of -hosts)

> in one document, and the recommendatoin we want hosts to implement

I think the important thing is clarity.

> should probably be moved to cpl.

Or the other way around, depending on whether you see
CPL as the core, or a component in the description...

I'll have a look through both documents, and see how much
redundancy and waffle there is (within the documents and
between them).  I'll try to post a per paragraph analysis
overnight.

> with each other), I'd like to hear it.

Indeed.  At least we can cut down redundant information.
If the documents are co-dependent, then it may be OK to
combine them.

Others' opinions are earnestly sought.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 08 Feb 2006 10:34:37 -0800

> Why? And what is the benefit of keeping them separate?

Perhaps the WG viewed it as the path of least resistance when dealing 
with multiple already existing documents?
Another path of low resistance is to concatenate the two documents, but 
I don't think that makes things any more clear for the reader.

> in one document, and the recommendatoin we want hosts to implement

Did you find background material in DNA hosts that would fit into a 
"design considerations" type document?

We have at least two things in the CPL document which could be moved to 
such a document (the probability calculations, and section 5 that you 
asked we remove and that Mohan wants to keep as interesting reading).

FWIW Once we have a path forward for these two documents, I think there 
is a corresponding issue with the "unmodified router" and "modified 
router" documents (CPL/hosts draft vs. DNA protocol draft) in that
  - there is some things that are common (when/how to do MLD, DAD, and 
the description of the 'link up' event)
  - a host implementor would find it easier if both were described in 
the same place.
But a router implementor only cares about a subset of what is in the DNA 
protocol draft.

    Erik