Re: [802.21] FW: [DNA] Review of draft-ietf-dna-link-information-03.txt
There is a preliminary work on this:
21-06-0608-00-0000-Link-Identifier.doc
Your comments are appreciated.
Yoshihiro Ohba
On Tue, May 23, 2006 at 09:15:01PM -0700, Michael G. Williams wrote:
> 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
> >
> >
> >
>