Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> > 
> > 
> > 
>