Subject: Re: [DNA] Link Identification Scheme ComparisonPowerpointslides

From: Sathya Narayanan <[email-masked]>
Date: Thu, 04 Aug 2005 08:09:07 -0400

> Comparison 9:    I think Landmark also depends on CPL on DNA-nonDNA
> movement. There is no way that the Landmark can make decision on its own.

As mentioned in the footnotes in the additional information section, it is the CompleteRA component which helps with building of the CPL (see Comparison 4), which makes it a 'Yes' for the Landmark/CompleteRA column.

> Comparison 10: Support for Mixed Links
> 
> Whether you consider this case different from the Comparison 8.
8, 9, 10 and too some extent 4 are related - different aspects of a underlying concept.

> I guess its the case when the one link have both DNA and non-DNA Routers.
Yes.

> I think this the same problem with the Landmark if the new router comesup in the same link.
I am not sure I understand this comment - new router coming up on a link introduces some kinda instability to both link identification mechansim (I guess it was refered to as flashing on the mailing list).

> 
> Comparison 11: Support for the # of prefixes
> 
> I think here again LinkId has advantage than Landmark. How does the Landmark have the advantage?
That was a bad choice of words, what I meant was - only the Landmark functionality will be available when there are large number of prefixes so that they don't fit in a single RA message. 

> Also I think following points shall be added in the comparison list.
> 
> 1) Synchronisation
> 2) No of new options
> 3) Support for neigborhood information discovery protocols like NED, CARD

I don't think 1) and 2) are useful. And I don't know about 3). Lets discuss it further.

thanks for your comments,
Sathya

> ----- Original Message ----- 
> From: "Sathya Narayanan" <[email-masked]>
> To: "Greg Daley" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, August 04, 2005 2:35 PM
> Subject: Re: [DNA] Link Identification Scheme Comparison 
> Powerpointslides
> 
> > The latest comparison slides to be used during the meeting can 
> be found 
> > at:
> >
> > http://www.ctie.monash.edu.au/dna/DNASolnComparison_4Aug2005.ppt
> >
> > Please take a look at it and provide feedback.
> >
> > thanks,
> > Sathya
> >
> > ----- Original Message -----
> > From: Greg Daley <[email-masked]>
> > Date: Friday, July 29, 2005 3:39 pm
> > Subject: [DNA] Link Identification Scheme Comparison Powerpoint 
> slides>
> >> Hi,
> >>
> >> Here is a comparison of the different Link Identification features
> >> available in draft-pentland-dna-protocol and draft-jinchoi-dna-
> >> protocol2
> >>
> >> It's aimed at providing a feature distinction, although there are
> >> also a couple of outstanding issues to be considered separately.
> >>
> >> http://www.ctie.monash.edu.au/dna/DNASolnComparison_28July2005.ppt
> >>
> >> Greg
> >>
> >
> >
> > 
> 
>

---

From: Ranjitsinh Wable <[email-masked]>
Date: Thu, 04 Aug 2005 18:32:05 +0530

Hi Sathya,

See the comments inlined

----- Original Message ----- 
From: "Sathya Narayanan" <[email-masked]>
To: "Ranjitsinh Wable" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 04, 2005 5:39 PM
Subject: Re: [DNA] Link Identification Scheme ComparisonPowerpointslides

> As mentioned in the footnotes in the additional information section, it is 
> the CompleteRA component which helps with building of the CPL (see 
> Comparison 4), which makes it a 'Yes' for the Landmark/CompleteRA column.

Here  again I will say that the Complete RA will aid to create the Complete 
Prefix List Faster after that the
mechanism is same.

Lets say that host on the previous link have the complete prefix List
(How they get that list, mechanism may be different), On movement from DNA 
to non-DNA
they have to check the prefix list in the new RA to the complete prefix 
list.
So that way the mechanism remains same. There is no different case for both 
the
methods.

> I am not sure I understand this comment - new router coming up on a link 
> introduces some kinda instability to both link identification mechansim (I 
> guess it was refered to as flashing on the mailing list).
>
I think, I was too abstract to convey the point. Sorry for that I will try 
to put it in different way,

Supose in the mixed link host gets the RA. Link ID will consider the the 
Link change process
if it gets the L2 trigger bcoz it don't know whether its non-DNA node of 
same link or
RA from new Link.

Now lets consider what happens in the Landmark case. Now if the new RA 
advertise prefix which is
 not present in the Complete prefix List available with host. (Your bracket 
case from ppt).
Host don't know its new router on same link or new router on the next link.
So the requirement is agin same.
> That was a bad choice of words, what I meant was - only the Landmark 
> functionality will be available when there are large number of prefixes so 
> that they don't fit in a single RA message.
>
Yes, you may need to rephrase it.

Regards,

Wable R. U.

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Thu, 04 Aug 2005 16:50:10 +0200

I tried to ask the following question during the DNA jabber session, but 
that didn't quite produce the result I was hoping for and so I send
this on the mailing list instead:

Does anyone know about a link technology which fails to report a link-up 
hint?

/Tero

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 04 Aug 2005 17:31:23 -0400

Tero,

I don't have a technology in mind, but from an implementation point of 
view, maybe some nodes won't implement Link Up.

Nicolas

Tero Kauppinen (JO/LMF) wrote:

> I tried to ask the following question during the DNA jabber session, 
> but that didn't quite produce the result I was hoping for and so I send
> Does anyone know about a link technology which fails to report a 
> link-up hint?
>
> /Tero
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 04 Aug 2005 08:59:40 -0700

> view, maybe some nodes won't implement Link Up.

And some nodes won't implement DNA ;-)

We could very say that if you want to implement DNA, then you need to 
implement link up.

That isn't much different than saying that if you want to implement TCP, 
you need to implement the 16 bit Internet checksum algorithm.

Hence the question is whether this would cause a problem for some types 
of links, where there is something in the L2 design that makes it hard 
for a device driver to provide a link up event notification.

   Erik

---

From: Marc Manthey <[email-masked]>
Date: Thu, 04 Aug 2005 18:22:51 +0200

On Aug 4, 2005, at 5:59 PM, Erik Nordmark wrote:

> Nicolas Montavont wrote:
>
>> Tero,
>> I don't have a technology in mind, but from an implementation  
>> point of view, maybe some nodes won't implement Link Up.
>>
>

http://www.dns-sd.org/ServerSetup.html

---

From: Greg Daley <[email-masked]>
Date: Fri, 05 Aug 2005 16:09:49 +1000

Dear Marc,

It is hard to tell what the relevance of your e-mail.

If you're posting URLs to the list which don't have clear
and obvious relevance to the topic of conversation, it
is appropriate to identify the relevant material.

Please do so, otherwise you add nothing to the conversation.

Greg

Marc Manthey wrote:
>>> I don't have a technology in mind, but from an implementation  point 
>>> of view, maybe some nodes won't implement Link Up.
>>>
>>

---

From: Marc Manthey <[email-masked]>
Date: Fri, 05 Aug 2005 09:45:06 +0200

dear greg ,
thanks  for  the  reply ,  Bonjour uses unicast DNS Service Discovery  
[DNS-SD] along with DNS Update [RFC 2136].
  Since  OS X r includes the standard BIND DNS Server (named) with  
support for DNS Update, it makes a great Bonjour name server.
It's also recommended that you run the dnsextd daemon alongside  
named. dnsextd implements DNS extensions that enhance service discovery.

marc

--  

Les Enfants Terribles
www.let.de

---

From: Greg Daley <[email-masked]>
Date: Fri, 05 Aug 2005 18:36:04 +1000

Dear Marc,

This is not a list about DNS.

Marc Manthey wrote:
> It's also recommended that you run the dnsextd daemon alongside  named. 
> dnsextd implements DNS extensions that enhance service discovery.
> 
> marc

Please keep your on-list comments to Detecting Network Attachment in
IPv6.

Discussions of other topics unrelated to DNA (note: this is not DNS)
are not appropriate.

Please see "Inappropriate Postings to Discussion Lists" at
the URL:

http://www.ietf.org/maillist.html

and the RFC regarding control of mailing list postings by
Working Group Chairs.

http://www.ietf.org/rfc/rfc3934.txt

Please contribute to the topic at hand, rather than posting
distracting and unrelated information.

Yours Faithfully,

Greg Daley,
DNA Co-Chair

---

From: Marc Manthey <[email-masked]>
Date: Fri, 05 Aug 2005 10:45:34 +0200

> This is not a list about DNS.
dear greg

sorry for my  mistake , a little letter makes  a big different.;)

regards and sorry again

-- 

Les Enfants Terribles
www.let.de