[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] DNA Goals Issues
Dear Jim
Thanks for your detailed comments. I like your opinion about disagreement
and also will try that we disagree in an agreeable way. :-)
I understand that you propose that the parts of Goals drafts
1) be removed and
2) be made a separate draft, if possible.
After clarifying the parts to be removed with your confirmation, I will
start threads about whether we remove it or not.
I ask chairs whether the separate draft is possible.
It's ok for me to remove the parts of the draft that WG does not consider
indispensable. For me, The less the better.
I only wish you gave this input when I submitted the previous version. That
would have saved lots of my efforts.
Also there are a few statements that we disagree on their validity.
To break a deadlock to speed up the process, I request reviewers
(Greg & Pekka) to express their opinions on the contending issues.
The draft went through reviewing process more than 2 months.
Kindly find my in-line comments.
> I know what a link and AP is and I await WG consensus I believe that is
> close. No other comments on that.
Glad to hear that.
> > 2. Analysis parts
> > Goals drafts contains the analysis related parts, Sec 2 DNA
> > in Existing IPv6 Systems and Sec 3 Problems in DNA. I
> > understand that you suggest to cut them down.
> >
> > It was our intention to present the current state of art of
> > DNA, without evaluating the pro and con of the possible
> > solutions. We aimed to describe the limitation of the
> > existing IPv6 to clarify the Goals.
>
> The limitations in your opinion should be a separate draft is my main
> objection. This way we discuss and get consensus on that specifically
> and I believe that would be useful to the WG and not interfere with
> getting consensus on the goals. I for one do not agree with all of your
> assumptions about IPv6 and have said so all along. Separate the two and
> lets not put your views in the goals doc and cause it to hold up
> consensus on the goals.
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.
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.)
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?)
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.
> > We thought that it would be useful for Goals draft to include
> > some analysis but you seemed to disagree. Right? Kindly
> > confirm yourself.
>
> I NEVER said that please do not put words in my mail. I never said no
> analysis is not required I said stating what is wrong with IPv6 in an
> IETF permanent document (in other words before) is inappropriate in a
> goals document. It is to important for documentation and this WG
> process.
Some analysis may be inappropriate for the goals drafts. But I suspect many
of them are plain wrong (conflicting with facts). But I suggest that we concentrate
on deciding whether a statement to be included or not
in the draft, rather than arguing over whether it is valid or not. If the
inclusion decision depends on the validity, then we may argue about validity.
> > If so, I will start a thread about this and in case WG decide
> > to remove the analysis parts, we will remove them or generate
> > a separate draft.
>
> Yes but lets not call it analysis.
ok.
> > I wish we take a pragmatic approach, (rather than dogmatic).
> > We'd better make a decision based on whether it would help
> > Goals draft to include analysis part or not.
>
> What analysis is the key not analysis. I think my mail above makes
> clear what I consider inappropriate analysis.
ok.
> > The second part is more about analysis. In case WG decide to
> > do away with the analysis, we will make a modification accordingly.
>
> I am trying to follow IETF status quo and rules of engagement. I don't
> know of a single document that has two paragraphs in the IETF for the
> abstract? If I am wrong I simply have not seen it and review many
> documents in the IETF.
I thought that, instead of one long paragraphs, two short ones are easier
to understand.
> > The host only changes it's link-layer connection. It's not
> > certain whether it moves to a new link or not yet.
>
> Hmm terminology issue. If it changes its link connection it either has
> moved or on two different links.
Yes, terminology is confusing. Kindly take notice that the host changes
its link-layer connection, NOT link connection. I differentiate 'link-layer
connection' and 'link connection' and avoid the second term entirely.
A host can change its link-layer connection without neither moving to a
new link nor being on two different links at the same time.
> 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.
A host can hear both links if it has two separate interfaces, for example
3Gpp & 802.11b. Can one interface be attached to two different links?
> > > > While other information for IP connectivity (such as DNS server
> > > > configuration) is also important, obtaining most of such information
> > > > depends on the determination of correct global addressing and valid
> > > > default router configuration.
> > >
> > > I think the paragraph above needs work. I could find all this on a
> > > link with no router at all. Or clarification.
> >
> > The above is not clear to me. You could find all 'WHAT'?
>
> DNS server, DHCP server, SL servers, X.500, PKI server etc.
ok. I will modify the paragraph.
> > > > Hence, to determine the need of a further configuration, a
> > > > host needs to check at least that:
> > > >
> > > > 1) Whether it knows a (partially) reachable default router.
> > >
> > > I don't think this is true unless you add on a new link.
> >
> > A host is under uncertainty. It doesn't know whether a link
> > change happened or not.
>
> This is where we do not agree and we can agree to disagree. Point of
> further discussion for sure.
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.
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?
> > > Not sure about this. How is this possible. If I can get a packet
> > > from an address then I can send to an address? Does this need to be
> > > worded differently or more explanation.
> >
> > Assume I receive an RA from a new Router. It confirms that I
> > can receive a packet from the router. But it doesn't confirm
> > the router can receive a packet from me.
>
> My point is that the only technology that has this asymetric property
> are radio transmissions not 802.xx protocols wired or wireless. Is my
> understanding. So lets keep it focused and this is another goal for DNA
> to define the L2 properties with respect to routing and link detection.
You suggest as a DNA goal the following.
Define the L2 properties with respect to routing and link detection.
I wonder this may be under link-layer hint work.
> > I had in mind the case of changing APs while staying on the
> > same link with huge L2 handoff delay, the period between
> > deassociation with an old AP and reassociation with a new AP.
> > For example, Boeing people are using 4 satellites around the
> > world to get 5Mbps downlink to the airplanes, and it takes
> > 30sec for the airplane to handover from one satellite to the
> > other. In such cases, I thought DAD & NUD is necessary even
> > when a host is attached to the same link.
>
> Ouch :--). I thought you were speaking of addresses so that needs to be
> crystal clear. But I do nto support changing ND parameters unless they
> are done with RA updates or DHCPv6 or Sys Admin hard configuration, not
> based on hueristics that's insane idea technically.
ok.
> > > OK I agree but shouldn't this be part of a solutions section and is
> > > this a goal?
> >
> > I thought this as ALSO goal. 'Detecting link identity' is a
> > MUST goal.
> > This is 'Would be nice" Goal.
>
> I think it is mandatory goal.
ok.
> > > OK now we are in the solution space not goals.
> >
> > I see. You want this removed?
>
> That is my input I think WG should have healthy discussion on the
> analysis the only part of analysis that is very bad and I will object to
> all the way to last call are any statements stating what IPv6 does or
> does not do. But analysis should be slim in a goals doc or why have
> goals of you have the analysis done? Analysis should make the goals
> clear and that is not what is done in current draft.
I see.
[omitted]
> > > This is not a goal. I don't agree with #3 if I know at #3 my link is
> > > changed then RS/RA/NS/NA are all on the new link.
> >
> > Host can't decide whether it moves to a new link or not by
> > receiving just a single RA (or NA).
>
> I believe hueristically it can and with other data from L2. But that is
> not relevant to the goals and again this should not be discussed in the
> goals draft.
I see.
> > This is the current state of art.
>
> I don't agree that is invalid statement on state of art there is no real
> deployment of MIPv6 yet to even say this or IPv6 with WiFi etc.
While no real deployment, there are several MIPv6 implementations. But I
suggest we stop arguing about 'the existing DNA schemes', lest we should
jump into ontology to ponder upon what it means to EXIST. For me, already
more than enough metaphysical discussions with bean counters. I promise to
keep away from the term, 'existing DNA schemes'
> > > 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?
> >
> > I think the difference of link definition results in the
> > above difference of opinions.
> > In WiFi, the link layer can notify the identity of the
> > current link-layer connection, maybe BSS, but can't indicate
> > the identity of a currently attached link.
>
> That I am checking now. And as I said this may be a requirement to
> IEEE.
thanks.
> > > > 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.
Do you want the above paragraph removed? Kindly clarify.
> > > This has nothing to do with Goals and a podium to present one view.
> > > RA's are not to represent link change so lets make one.
> > > But this is a goals document.
> >
> > DNA Goal is to 'detect a link identity'. Isn't it useful to
> > write that an RA can't indicate a link identity?
>
> If stated a goal is to make RA's provide link IDs then yes that would be
> a goal but state they can't without corresponding goal sounds like extra
> baggage and no value and potential political wordsmithing that is not
> relevant to the goals document.
So do you suggest to remove the above part? Your proposal regarding
Sec 3 is not entirely clear to me.
> > > > 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?
Either
1) remove the part or
2) modify the part to refer non-link-local scope.
> > > 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?
> > > > For rapid attachment detection, hints can be used to tell a host that
> > > > a link change might have happened. This hint itself doesn't confirm
> > > > a link change, but can be used to initiate the appropriate
> > > > procedures.
> > >
> > > Correct but lets go look at the IEEE properties of each link media
> > > first and be sure.
> >
> > There are hints from L3.
>
> Ugggggggggg. That should be a goal to verify.
Hints activate DNA procedures. MIPL code used to activate MD procedure
whenever it receives a new RA (the RA with a new IP address & prefix).
The receipt of a new RA is a hint.
> > > > 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).
> > That part is about the existing schemes, not the proposed solutions.
>
> I think all schemes need review existing and new ones. As I said above
> there is no MIPv6 mobility in the production world today but it is
> beginning that is for sure and DNA is late.
I am agree that DNA is late.
Thanks for your comments.
Best Regards
JinHyeock