[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] RE: DNA Goals Issues
JinHyeock,
> 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.
Not clear what you mean above. I don't think anyones mail has been
impolite.
>
> 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.
Yes because they are not goals..
>
> 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
Yes.
>
> 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.
Yes.
>
> 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.
Usually the case but not always.
>
> > > 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.
OK.
>
> > > 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).
By using 0 as the value.
I think we are done with this thread. Thanks.
/jim
>
> Thanks for your kind consideration.
>
> Best Regards
>
> JinHyeock
>
>