[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] DNA BCP Submission
Sathya
> >Thanks. Also kindly clarify what this draft's stance w.r.t link identity detection.
> >The above phrase gave me an impression that it tries to present a way for
> >DNA WITHOUT link identity detection. Am I right?
> >
> >
> No. We are not trying to present a way for DNA without link identity
> detection. On the other hand, we are
> not trying to define a unique 'link identifier' in this document either,
> except in the CPL section. (Greg, Nocolas -
> if you disagree with my understanding, please correct me). As Pekka
> pointed out during an earlier discussion,
> we could achive link identification without having a specific identifier
> assigned to each link - in other words, two
> node in the same link can have different identification mechanism, for
> ex. one using CPL while another could wait
> for a RA with its current active prefix. Both mechanisms, have their own
> efficiency versus accuracy ratio.
"An RA with its current active prefix" can't represent a link change
properly. Hence, it can't be a link identifier, unless a host adopts CPL
technique. I am afraid we have a different notion about what link
identifier is.
With a link identifier, a host can properly determine whether
it still remains at the same link or not. If a host sees the same
link identifier, it means that it still remains at the same link.
If it sees a different link identifier, it means that it is attached
to a different link.
We wrote, in "DNA solution framework" draft,
............................... Each link has its unique Link Identifier and all
routers in the link advertise the same Link Identifier in RAs. With
a Link Identifier, an RA can represent a link identity and hosts can
check for link change immediately without resorting to approximate
knowledge.
When a host receives an RA with the same Link Identifier, it still
remains at the same link. If it receives an RA with a different Link
Identifier, a link change has occurred and the host is attached to a
different link.
Link identity detection is supposed to check for link change. If you
present a way for link identity detection without link identifier, that
would be nice but the only alternative (without standard change)
I can think of is CPL.
> >I don't think it's wise to include other helpful, but not relevant to DNA, features
> >in DNA BCP draft. For example, I hardly see how Sec 8.6 is relevant to DNA.
> >I think all it says w.r.t. DNA is "after a link change, MN should get CoA & send
> >BU".
> >
> >
> ;-) I agree, 8.6 could possibly go - it is more of a place holder right
> now and we may cut it later. But, what about
> all the other sub-sections in 8, and 7, 9,11 etc. 10 could possibly move
> to an appendix.
> During the last meeting, I got the sense that the working group wanted
> to keep BCP as the place were lot of the
> additional issues like MLD, ND cache etc. are discussed. If the group
> feels otherwise, we could either cut them or
> move them to the appendix.
What concerns me the most is NOT the draft includes many uncruicial
things BUT it doesn't include enough crucial things. Also I am afraid
that too much focus on uncrucial things may prevent crucial things
from getting enough attention.
> >In my opinion, DNA BCP draft would better focus on DNA procedure.
> >Wiht link identity detection, how to check for link change &
> >Without link identity detection, how to ensure 1) default router (partial)
> >reachability & 2) existing IP address (prefix) validity.
> >
> >
> I don't know if DNA is possible without link identification conceptually
> whether or not a unique (for
> all nodes) 'identifier' is used. See my response below:
A host may skip to check for link change and directly verify
IP configuration one by one.
> >Correct me if I am wrong, but Sec 4, 5 & 6 hardly tell about
> >'how to verify the existing IP address'. I failed to find it and
> >the content list is of little help.
> >
> >Also kindly bear in mind that I mean
> >
> >'to verify the validity of existing IP address'
> >
> >as
> >
> >'to verify that the prefix of existing IP address is supported on
> >the currently attached link'.
> >
> >IP address can be called really valid only after DAD completion
> >but it's not my intention to include DAD in DNA.
> >
> >Neither they tell enough of how to confirm (partial) reachability
> >in the presence of link-local router address, where there are
> >plenty about bi-directional reachability confirmation.
> >
> I don't think it is reasonable for me to argue that sections 4, 5 & 6
> are answering the question
> 'how to verify the exiting IP address', if you (as a reader) don't agree
> ;-) I will note this as part
> of the issues and try to do a better job in -02.
Thanks.
> >Actually, the two seem the only confirmations that are relevant to
> >DNA. Right now, I don't see any other configuration that need to
> >be verified for DNA.
> >
> >
> Again, other configurations like MLD, ND etc., are not directly relevant
> to DNA - and the
> question is back to whether the focus of BCP must be restricted by the
> goals or not. I will
> raise this question during the meeting to get some consensus from the group.
I guess the issue is more of 'priority' rather than 'restriciton'. I think
the BCP focus should be primarily on the DNA relevant stuffs. If
those are adequately dealt with, we may work on other less-relevant stuffs.
In organizational point of view, however, I would like secondary stuff
be in another draft or appendix.
> >Kindly, take notice (partial) Reachability, NOT bi-directional one. In goals
> >draft-00, I wrote as below.
> >
> I understand.
ok.
> >IMO, w.r.t DNA, it's enough for a host to detect that it can hear from
> >the existing default router. In DNA point of view, bi-directional reachability
> >is 'nice to have' feature, NOT 'need to have' one. If necessary, after DNA
> >completion, ND (RFC 2461) can kick in to establish bi-directional reachability.
>
> I agree. Don't you think, if bi-directional reachability can be
> confirmed without additional cost as part of
> DNA procedure, it makes sense to do so? I thought the goals draft allows
> (with a may) 'the collection of some of the
> necessary information for new IP configuration' as part of the DNA
> procedure, to reduce handoff delay.
> Same logic should apply here, if another 'nice to have' feature can be
> achieved with little or no additional cost.
I agree. It would be nice if a host can establish bi-directional reachability
while performing DNA.
> >Neither do I agree with 'any form of link-identification used for DNA is
> >going to be derived from the default router'.
> >
> >What do you suggest a host would do if prefix information & router information
> >conflicts each other, such as a host receives an RA that has the same link-local
> >router address but includes only new Prefix Information Options?
> >
> >
> My mistake - I didn't make myself clear - the way I look at it, in your
> example the new prefix options are still
> derived from the router and the link-identification depends on the
> information from the router.
ok.
> >DNA wrapped with DAD inside bi-directional reachability is hard to see!
> >:-(
> >
> >
> This is not an accurate description of the draft. If you don't read the
> additional information sections, you will not
> come across DAD. I agree that as the second step in DNA process we have
> presented bi-directional reachability.
> We will have to take a closer look at it.
ok.
> But primarily, I think, your concerns with the draft are because of a
> fundamental direction issue for the BCP.
> Do we to a large extent restrict the scope of BCP based on the goals
> draft or not? I think this question must be
> answered in the next meeting.
As I wrote above, this is about not so much as 'restriction' but 'priority'.
issue. I understand that DNA BCP draft is about 'how to perform DNA
without standard change'. What bothers me about the draft is not
it includes many other stuffs but it doesn't include enough DNA stuff.
IMO, the draft says much about secondary stuffs, such as DNA & DAD,
but doesn't pay enough attention to DNA itself, especially link identity
detection. It hardly say about how a host check for link change.
For example, after a hint of a possible link change, assume a host
receives a RA with a link-local router address that is identical to
the currently stored default router address. How does the draft
suggest host would determine the identity of the currently attached
link? Can it assume that it still remains at the link based on link-local
address? If so, what would be the risk? If not, what further activities
the host would take to corroborate the decision? Also how much
time it would take to perform all this activities and how to minimize
the delay. I failed to find a guide for hosts in such situations.
The main issue should be whether the draft deals with DNA adequately
or not. If so, either way is ok for me about whether to include other
stuffs or not. If not, the draft would better work on DNA proper, instead
of payint too much attention on secondary stuffs.
Thanks for your kind consideration.
Best Regards
JinHyeock