RE: [dhcwg] dhcpv6-24: use of anycast

"Bound, Jim" <Jim.Bound@hp.com> Mon, 13 May 2002 02:15 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10687 for <dhcwg-archive@odin.ietf.org>; Sun, 12 May 2002 22:15:00 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22054 for dhcwg-archive@odin.ietf.org; Sun, 12 May 2002 22:15:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21922; Sun, 12 May 2002 22:13:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21888 for <dhcwg@optimus.ietf.org>; Sun, 12 May 2002 22:13:33 -0400 (EDT)
Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10621 for <dhcwg@ietf.org>; Sun, 12 May 2002 22:13:20 -0400 (EDT)
Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 182A270B; Sun, 12 May 2002 22:13:31 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:13:31 -0400
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [dhcwg] dhcpv6-24: use of anycast
Date: Sun, 12 May 2002 22:13:30 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B1@tayexc13.americas.cpqcorp.net>
Thread-Topic: [dhcwg] dhcpv6-24: use of anycast
Thread-Index: AcH5uqmZmsfzZBhPRi2jGTyBU2Mt/wAaOuFQ
From: "Bound, Jim" <Jim.Bound@hp.com>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, Thomas Narten <narten@us.ibm.com>
Cc: Ole Troan <ot@cisco.com>, Ralph Droms <rdroms@cisco.com>, dhcwg@ietf.org
X-OriginalArrivalTime: 13 May 2002 02:13:31.0019 (UTC) FILETIME=[C6DBFDB0:01C1FA23]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA21893
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 8bit

Bernie,

Nope I was stating if I want to know if confirm is multicast I can.  Not having an API is a non issue.

/jim
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Sunday, May 12, 2002 9:41 AM
To: Bound, Jim; Thomas Narten; Bernie Volz (EUD)
Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: use of anycast 


Jim: 
Did you mistype here ... "This is not a good argument IMO for confirm."? What does anycast have to do with Confirm (well, the message might need to be anycast in NMBA networks but so would a Solicit, Information-Request, Rebind, ...).
- Bernie 
-----Original Message----- 
From: Bound, Jim [mailto:Jim.Bound@hp.com] 
Sent: Sunday, May 12, 2002 12:58 AM 
To: Thomas Narten; Bernie Volz (EUD) 
Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org 
Subject: RE: [dhcwg] dhcpv6-24: use of anycast 


One thing I don't agree with is that its hard to figure out of you have multicast existent on an interface?  All of us support some form of sysconf to do that.
This is not a good argument IMO for confirm. 
(I am not against confirm) but to have it because of the API comment is not good). 
/jim 
> -----Original Message----- 
> From: Thomas Narten [mailto:narten@us.ibm.com] 
> Sent: Thursday, May 09, 2002 9:23 AM 
> To: Bernie Volz (EUD) 
> Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org 
> Subject: Re: [dhcwg] dhcpv6-24: use of anycast 
> 
> 
> > The only issue with this is that DHCP usually runs as an application 
> > and is therefore only able to access that information which the 
> > lower layers (via APIs) make available. 
> 
> Understood. 
> 
> > Determining whether multicast is supported or not is pretty standard 
> > from the socket API. However, determining that a particular 
> > interface is a specific media type may be difficult. 
> 
> OK. 
> 
> > Therefore, there is some value in providing a clear direction here 
> >  that is also relatively easy to implement. 
> 
> Agreed. 
> 
> > If all interface types provide multicast (either inherently or via 
> > some type of emulation), there is little need to ever use the 
> > anycast address and so what harm is there in specifying it. 
> 
> The harm is that a) we may define something that isn't useful (which 
> may cause problems when deployed because some implementations choose 
> use the feature even if it doesn't work as intended). b) clients may 
> choose to send to anycast addresses, but if servers aren't configured 
> to deal with them, we don't get interoperability, so specifying that 
> clients MAY do something really implies (to me) that server SHOULD (or 
> maybe even MUST) be prepared to handle such packets from clients. If 
> the client  can't expect a server to handle something, there is little 
> point in clients implementing the feature either. 
> 
> My general opinion: if its not clear something is useful, and it's not 
> obvious what the details should be, including the feature distracts 
> from the overall goal of getting the spec done. The more one can 
> remove, the fewer details that have to be gotten right. 
> 
> > What we probably should say is that the client MUST use the 
> > multicast address if the interface on which it is sending the 
> > message supports multicast. Otherwise, it may use the anycast 
> > address. 
> 
> This is OK with me. Just so long as it's clear that the anycast usage 
> is only link-local and is only for reaching servers (and relay agents) 
> on the same link. This seems like a straightforward thing to get 
> right. 
> 
> Thomas 
> 
> _______________________________________________ 
> dhcwg mailing list 
> dhcwg@ietf.org 
> https://www1.ietf.org/mailman/listinfo/dhcwg 
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg