RE: FW: [DNA] Review of draft-ietf-dna-link-information-03.txt
Colleagues,
This is a call for interest to participate in the link layer
identification issue within 802.21. Please send email if you have the
bandwidth and interest to participate. If you want to monitor, don't
worry the group's discussions and outputs will be available publicly.
Yoshi, thanks for reminding me one of the issues is about link-id and
that I am to drive a resolution. I agree that for the IEEE definition we
want something related to the two or more endpoints connected together.
<opinion>
I believe that an ID is just that, not an address. IP has overloaded the
two functions (esp with CGA), and so has the IEEE MAC, in my opinion.
If we want to create an ID that similarly overloads/combines the two
functions (address and identification) so that a link id could be used
to route/address to the link, or be used to identify the link for
descriptive, relational, organizational or authentication/authorization
type purposes, then we need to combine both address and identification
functions.
If we want to create just an ID that does not help in
routing/addressing, then I think a globally unique identifier with some
cryptographic property would be the ideal, and we could consider
compromises less than that.
I also agree that for multicast/broadcast or bridged or switched, a
slightly different form/derivation of ID or combined ID/address would be
appropriate.
I don't know how tightly connected we need to make our link id to the
DNA definition.
</opinion>
Best Regards,
Michael
-----Original Message-----
From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
Sent: Tuesday, May 23, 2006 7:28 PM
To: Williams Michael.G (Nokia-ES/MtView)
Cc: yohba@tari.toshiba.com; Greg.Daley@eng.monash.edu.au;
vivek.g.gupta@intel.com; Qiaobing.Xie@motorola.com;
xiaoyu.liu@samsung.com
Subject: Re: FW: [DNA] Review of draft-ietf-dna-link-information-03.txt
Michael,
I saw you asked DNA WG at least two things as far as I know, one is on
usefulness of 802.21 link-down event the other is on link
identification.
For link-down events, DNA members answered that link-down indication
itself is not much useful, but for other events, DNA (implementations)
can use .21 events as L2 hints as Greg mentioned.
For link identification, I'm afraid DNA link identity is not useful for
identifiying a link defined in 802.21, because the DNA's defintion of
"link" is IP link. Interestingly, draft-iab-link-indications-04.txt has
slightly different definition of
link:
"
Link A communication facility or physical medium that can sustain data
communications between multiple network nodes, such as an Ethernet
(simple or bridged). A link is the layer immediately below IP. In
a layered network stack model, the Link layer (layer 2) is normally
below the Network (IP) layer (layer 3), and above the Physical
layer (layer 1). Each link is associated with a minimum of two
endpoints. Each link endpoint has a unique link-layer identifier.
"
Saying that "each link is associated with a minimum of two endpoints",
their definition of "link" is something different from IP link, because
if there are N hosts in the same Ethernet LAN, then it will have N*(N-1)
links. I will ask Bernard on this.
Yoshihiro Ohba
On Tue, May 23, 2006 at 03:15:15PM -0700, Michael.G.Williams@nokia.com
wrote:
>
> Yoshi,
>
> I must admit to some confusion about DNA. Greg was attending and
> contributing significantly to .21 at one time. From the lack of
> interaction and communication at the member level and at the WG level,
> what are we to conclude about the IETF interest in .21? I asked
> explicitly if DNA could make use of L2 hints and the only reply I got
> was NO.
>
> The MIP folks also seem to have nothing to say about the work. Can you
> help me to understand if I should be doing something to create more
> requirements/dialogue / discussion of .21 within these key mobility
> groups?
>
> Best Regards,
> Michael
> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of ext Jari
> Arkko
> Sent: Tuesday, May 23, 2006 6:48 AM
> To: Bernard Aboba
> Cc: dna@eng.monash.edu.au
> Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt
>
> FWIW, I agree with most of Bernard's comments. Some further discussion
> below:
>
> > a. The document appears to apply to both IPv4 and IPv6, but it makes
> > a
>
> > number of statements that do not reflect the operation of DNAv4 as
> > defined in RFC 4436. For example, DNAv4 does not utilize "link
down"
> > events or make use of link layer "hints".
>
> > This abstract does not clearly indicate the purpose of the document.
> > It would be helpful to state that the primary purpose is to address
> > events relating to DNAv6 (since the document does not appear to
> > apply to DNAv4).
>
> If we take a strict interpretation of the charter, the DNA WG is only
> chartered to look at IPv6. Having said that, a version agnostic
> document would in my opinion be useful, assuming we could make it
> acceptable. I'm not sure why there would be a need for the v4 and v6
> case to differ much, since *this* document should not describe the
> actual DNA process
> -- just input for the process, such as the "link up" event.
>
> Also, I can not see where the "link down" event is used even in DNAv6
> -- draft-ietf-dna-protocol uses "link up"
> only, just as DNAv4. But is it used somewhere else? If not, perhaps
> the right thing to do is to focus only on the "link up" in this
document.
>
> >
> > " BSSID and SSID MUST be provided as auxiliary information
> > along with the link up notification. Unfortunately this
> information
> > does not provide a deterministic indication of whether the
IP-layer
> > configuration MUST be changed upon movement."
> >
> > Given the limitations of the BSSID and SSID, why the normative
> > language? DNAv4 implementations will not use this information.
>
> I agree that the BSSID and SSID may be of limited value. If they are
> needed, at least MUST seems inappropriate.
>
> > " Link-Layer indications in Ethernet-like networks are complicated
> by
> > additional unadvertised delays due to Spanning Tree calculations.
> > This may cause re-indication (link up with A-flag) or retraction
> > (link up with B-flag) of indications previously sent to upper
layer
> > protocols."
> >
> > What are the A and B flags? Is this an artifact of a previous
> revision?
>
> Defined earlier in Section 2.
>
> Anyway, I have a question for you Bernard: draft-iab-link-indications
> talks about the importance of damping and hysterisis -- has that been
> sufficiently addressed in the wireless parts of the
> dna-link-information document?
>
> --Jari
>
>
>