[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] Re: DNA Goals Issues
Dear Jim
Sorry for a delayed reply. I was off the office, not for vacation
but for reserve training. (crawling beneath barbed wires under
the scorching Sun. :-))
> But of course and one cannot read into email unless it is rude and best
> to take it as android discussion in cyberspace.
I promise to read your mails even if they are polite.
No need to be rude to be read.
Let me summarize the issues you raised.
First you propose that the parts of Goals drafts be removed
and be made a separate draft, if possible.
The parts to be removed are
1) The second part of Abstract
2) Section 2. DNA in Existing IPv6 Systems
3) Sub-section 3.2. Inadequacies in RA information
Second you propose as a DNA goal the following three additional items.
4) Investigate a way for a host to attain and retain all prefixes
with certainty.
5) Analyze the case of the host hearing both links with respect to
seamless mobility
6) Describe the L2 properties with respect to routing and link detection
- This may be the work under either link-layer hint or bcp work.
Third you propose several parts to be clarified. I specify them it in-line .
Also It seems that several parts of Sec 1 need to be rewritten.
Kindly find my in-line comments. I also took the liberty to silently
ignore the parts where my response will be of little help to advance
the draft.
> We are all very busy and we do the best we can I have had this happen to
> me on drafts too. Also be prepared during a last call people will catch
> things that were not objected to before most likely.
Thanks for the warning. I will brace myself for that. But I wish people
will not dig the settled issues from the grave and restart the thread
again. I expect when an issue is over, it's over.
> > Also there are a few statements that we disagree on their validity.
>
> Do you mean you or "we"? Or I may misunderstand your sentence above.
Jim Bound & JinHyeock Choi.
> > You propose that the parts of Goals drafts
> > 1) be removed and
> > 2) be made a separate draft, if possible.
> >
> > I'd like to clarify the parts you suggest to be removed from
> > Goals drafts.
> >
> > I understand the parts to be removed are
> > 1. Seconds paragraph of Abstract
> >
> > Rapid attachment detection is required when a host has on-going data
> > traffic. Current DNA schemes are inadequate to support real-time
> > applications. The existing procedures for advertising network
> > information incur reception delays and do not provide enough
> > information to properly determine the identity of links. For
> > to-be-defined, efficient DNA schemes, a way to correctly represent a
> > link change, a complete and consistent procedure for network
> > information advertisement and a rapid delivery of the advertisements
> > will be necessary.
I understand that you propose to remove the second part of Abstract.
[omitted]
> > 2. All of Sec 2 DNA in Existing IPv6 Systems except the following two.
> >
> > Though the set of all the assigned prefixes may be used to represent
> > a link identity, it is difficult for a host to attain and retain all
> > the prefixes with certainty. Moreover there may be links without
> > any advertised prefix.
> >
> > (Jim's comments: Turn the above into a goal and suggest things to
> > look for in the goals.)
I understand you propose as a DNA goal the following
Investigate a way for a host to attain and retain all the prefix
with certainty.
> > Hence, to check for link change, as of today, a host must resort to
> > guessing, based on Router Discovery and Neighbor Unreachability
> > Detection (NUD). A host can examines whether 1) its existing default
> > router is still reachable and 2) its IP addresses are still valid.
> >
> > (Jim's comments: I can know I am on a new link from the link layer
> > and physical layer for WiFi, 3G, etc..Ethernet MACs are new. The
> > answer could be a new field in those layers and maybe we should look
> > at that and talk with IEEE?)
>
> Above is correct of my view.
I understand you propose to remove Section 2.
> > But your opinion about 'Sec 3 Problems in DNA' is not
> > entirely clear to me.
> > Kindly notify me whether you suggest that
> > 1) we remove the section altogether or
> > 2) we modify the section.
>
> This section is not appropriate for goals.
>
> 3.2 The Inadequacy of RA information
>
> Anything that discusses any thing other than general technology should
> be remove IMO esp. RA and RS statements.
I understand you propose to remove the sub-section 3.2
> > > Hearing both links is an interesting property of seamless mobility and
> > > requires analysis as a goal for this WG so I now suggest adding that
> > > as a goal.
>
> I agree.
I understand you propose as a DNA goal the following
Analyze the case of the host hearing both links with respect to
seamless mobility.
> > First I'd like to make it clear about what we do not agree,
> > because I suspect our difference of opinion is just a
> > difference of terminology.
>
> That could be.
>
> > My statement is that
> >
> > At the time a host changes its LINK-LAYER connection, it
> > doesn't know whether it still remains at the same LINK or not.
> >
> > Do you disagree with the above statement?
>
> I would say it "may' or "may not" know I think it is possible to know
> but we may need to add the prefix suggestion BCP or
>
> http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-02.txt
ok. I agree that 'may or may not know' is an adequate expression.
> > You suggest as a DNA goal the following.
> >
> > Define the L2 properties with respect to routing and link detection.
>
> Yes. But I would say "describe" and again that may be an info or bcp
> draft.
>
> > I wonder this may be under link-layer hint work.
>
> Could be yes.
ok. I understand you propose as a DNA goal the following
Describe the L2 properties with respect to routing and link detection
But this may be the work under either link-layer hint or bcp work.
> > > > > > 3.1 Wireless link properties
> > > > > >
> > > > > > 1) Unclear boundary
> > > > > >
> > > > > > Unlike wired environments, what constitutes wireless link is variable
> > > > > > in both time and space. It doesn't have clear boundaries. This may
> > > > > > be illustrated by the fact that a host may contact multiple (802.11)
> > > > > > access points at the same time. Moreover reachability on
> > > > > > a wireless link is very volatile, which may make link detection hard.
> > > > >
> > > > > Any device is aware of which wireless net is attached to and that
> > > > > data is available so I am unclear the statements above are valid?
> > > > > I also do not agree link detection is hard.
> > > >
> > > > In Wireless environment, a host may ping-poing between two links
> > > > rapidly. In that case, a host will have difficulty.
> > >
> > > I don't agree but define what exactly technically "difficulty" means above?
> >
> > What I have in mind is this. It takes time for a host to
> > detect the identity of a currently attached link. If the host
> > ping-pong between two links and doesn't stay enough time at a
> > link, the host can't complete detecting link identity.
>
> OK that is valid yes.
>
> > Do you want the above paragraph removed? Kindly clarify.
>
> I think clarify as you did above.
ok. I will clarify that.
> > > > > > 1) Link local scope of Router Address
> > > > > >
> > > > > > Usually a router address is contained in the source address field of
> > > > > > RA messages. That router address is link-local scope and its
> > > > > > uniqueness can't be guaranteed out side of a link.
> > > > > >
> > > > > > So if it happens that two different router interfaces have the same
> > > > > > link-local address, a host can't detect that it has moved from one
> > > > > > interface to another by checking the router address in RA messages.
> > > > > >
> > > > > > On the other hand, a host can't be sure that its default router is
> > > > > > reachable, even if it can communicate with the router that has the
> > > > > > same address as its existing router address. That router may be a
> > > > > > different one, which happens to have the same link-local address as
> > > > > > its default router address.
> > > > >
> > > > > We can require that the router use non-link local addresses with a
> > > > > prefix and those cannot be duplicated across the links. I am not
> > > > > advocating that but the above statement is not entirely honest or
> > > > > tells the whole story and also again not a goal.
> > > >
> > > > The above is about the existing problem of link-local scope of router
> > > > address.
> > >
> > > But is incomplete not referencing it can use non-link-local scope.
> >
> > I see. What would you suggest?
>
> I don't see the point of even discussing what the router does for goals
> but state what is needed.
>
> > Either
> > 1) remove the part or
> > 2) modify the part to refer non-link-local scope.
>
> Remove is my input.
ok
> > > > > So we fix that in RA's or add new RA fro mobile nodes.
> > > >
> > > > Under current standard, hosts can't be 100% sure that it knows all
> > > > the prefixes, even if it does. That uncertainty results in the
> > > > uncertain address validity determination.
> > >
> > > I simply 100% do not agree at all techncially that this cannot be done
> > > with a new set of RA's.
> >
> > It seems that you are worried the above may convey the wrong
> > impression.
> > Do you suggest the part to be removed?
>
> Just don't talk about solutions.
ok
> > > > > > 3) Random delay execution for RS/ RA exchange
> > > > > >
> > > > > > Router Solicitation and Router Advertisement messages are used for
> > > > > > Router Discovery. According to [4], it is sometimes necessary for a
> > > > > > host to wait a random amount of time to send an RS and for a router
> > > > > > to wait to reply an RA.
> > > > > >
> > > > > > Before a host sends an initial solicitation, it SHOULD delay the
> > > > > > transmission for a random amount of time between 0 and
> > > > > > MAX_RTR_SOLICITATION_DELAY (1 second). Also Router Advertisements
> > > > > > sent in response to a Router Solicitation MUST be delayed by a random
> > > > > > time between 0 and MAX_RA_DELAY_TIME (0.5 seconds).
> > > > >
> > > > > This is configurable.
> > > >
> > > > Configurable under RFC 2461?
> > >
> > > Yes.
> >
> > You mean that it is possible that
> >
> > Router Advertisements sent in response to a Router
> > Solicitation NEED NOT be delayed by a random time between 0
> > and MAX_RA_DELAY_TIME (0.5 seconds).
>
> Yes.
I don't understand it. According to 6.2.6 of RFC 2461,
6.2.6. Processing Router Solicitations
[omitted]
In all cases, Router Advertisements sent in response to a Router
Solicitation MUST be delayed by a random time between 0 and
MAX_RA_DELAY_TIME seconds.
Kindly tell me how the above can co-exist with the below. It seems
to me that they are logically exclusive.
Router Advertisements sent in response to a Router
Solicitation NEED NOT be delayed by a random time between 0
and MAX_RA_DELAY_TIME (0.5 seconds).
Thanks for your kind consideration.
Best Regards
JinHyeock