RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Sat Jun 16 2007 - 11:34:07 EDT

Ah... I haven't met a network admin yet who would prefer to manage their network data in each individual end-point versus having a common management database. That's even where there's only a couple of switches. When it comes to location, managing a database with a consistent (Switch-ID + Switch-port -> Location) schema is much simpler then dealing with the vendor specific mechanisms for managing the switch. That's why SNMP is popular after all. In terms of device capability, a network based location protocol like HELD can take advantage of a vanilla LLDP device because the switch port information can be sent to the LIS which has the location data to reference against. You don't need LLDP-MED to do that. You also don't really need LLDP to be used by the device because the LIS can learn the device to switch port association using many mechanisms including SNMP bridge MIB polling, DHCP-relay, DHCP lease query. That's before we get to the point where there's a generic framework for network devices to report location-related network parameters to the LIS. The NGES working group in ESIF are currently looking at formalising this using the LIS-ALE (FLAP) definition as a starting point. However, LLDP is nevertheless also a valid option. Yes, all these things work to provide at least basic location information and any given implementer has the option of using the approach that works best for them. However, it is better if devices can interact with access networks in the same way regardless of access technology - and not have to "know" it should be using LLDP-MED at this particular moment. When more sophisticated functionality (such as location signing, assertion, and location-by-reference) are required the L2 mechanisms also break down. Which brings me to a point I probably should have made at the beginning; the current topic on the thread started with the suggestion that while the identity extension draft mentioned LLDP, should it not also include LLDP-MED? The sense in which LLDP is pertinent is that it can be used to get a "transient identity component"; a switch/switchPort value for example. This information can be used to determine location. I assume LLDP-MED is raised because it provides a means to obtain location directly. However, "location as an identity component from which location can be determined" doesn't really fit with the identity-extensions. It more fits with the legion of alternative ways to get location in the first place. Cheers, Martin ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Saturday, 16 June 2007 4:11 AM To: Winterbottom, James Cc: GEOPRIV; Henning Schulzrinne Subject: RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt Hi again, > In LLDP-MED, the device are going to learn this stuff from SNMP ... Correct, where "device" here is the Network Connectivity Device (ie L2 switch), not the endpoint.  Endpoint does not need to support SNMP (can if it wants).  The switching infrastructure *can*, usually would, use SNMP in the process, but does not absolutely need to (read on).   > ... so isn't this simply a wiremap database that needs to be kept in synch with what changes at L2 as well? Yes, the wiremap dB does need to be kept in synch with L2 changes in *any* of the methods. In the LLDP / LLDP-MED based case, the interface to do this is well defined today (SNMP MIBs).   In a pretty real sense, the switching infrastructure itself can be considered as the "database" since all the information is actually held in the edge switches -- and where the least moving parts aspect comes in is that's the box on the other end of the physical wire from the phone.  Changes can be made directly at the switch side, and re-synched with a master dB in the higher level management system by SNMP polling, or changes can be made in the management system side and pushed to the switching infrastructure using SNMP.  Mismatches can also be detected by noticing that info read from the switch side does not match the management system side.  Either works, or mixture of both, and which is used I would expect to be a matter of system scale and operational preference.  Small systems (a few L2 switches) need no master dB or higher order management system at all -- it can readily all be done directly on the L2 boxes.   -- Peter "Winterbottom, James" <James.Winterbottom@andrew.com> 14.06.07 22:07                 To:        <peter_blatherwick@mitel.com>         cc:        "GEOPRIV" <geopriv@ietf.org>, "Henning Schulzrinne" <hgs@cs.columbia.edu>         Subject:        RE: [Geopriv]        I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt Hi Peter,   In LLDP-MED, the device are going to learn this stuff from SNMP, or at least that is what the documents I have read in the past suggested, so isn't this simply a wiremap database that needs to be kept in synch with what changes at L2 as well? Cheers James   ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, 15 June 2007 3:28 AM To: Winterbottom, James Cc: GEOPRIV; Henning Schulzrinne Subject: RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt   (oops, seem to have missed this one going by...) > What would you do in network configurations that support LLDP but not LLDP-MED, of which I suspect there are many? Upgrade.  Seriously, any of the location proposals will require upgrades, so it is really a matter of where, not if.  (Note I do not work for a networking vendor, so have no direct interest in network upgrades other than to make the deployment job easier, ongoing admin and TCO lower, and ECS more reliable.)   A corresponding questions to either L7 or DHCP methods is how would you get the wiremap data (ultimately L2 chassis/port ids and corresponding physical locations) into the server?  How to maintain it when things change at L2?  What's the standard interface for doing those important steps?   >> Hoping I'm not about to step on a land mine ... Please Note: I'm trying not to ignite a battle of methods here!  Though quite aware it could happen.  Original intent was to just point out that RELO did not really appear to be pointing to anything proprietary.  But thinking about it led me to wondering: in the presence of LLDP/LLDP-MED why it would not just be used directly, instead of indirectly through more moving parts.  Each of the methods has its place.   -- Peter   "Winterbottom, James" <James.Winterbottom@andrew.com> 11.06.07 18:35                To:        <peter_blatherwick@mitel.com>        cc:        "GEOPRIV" <geopriv@ietf.org>, "Henning Schulzrinne" <hgs@cs.columbia.edu>        Subject:        RE: [Geopriv]        I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt Hi Peter,   What would you do in network configurations that support LLDP but not LLDP-MED, of which I suspect there are many?   Cheers James       ________________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Tuesday, 12 June 2007 3:03 AM To: Winterbottom, James Cc: GEOPRIV; Henning Schulzrinne Subject: RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt   Hi, Hoping I'm not about to step on a land mine ... >  .. as opposed to something proprietary like Cisco Discovery > Protocolas RELO suggests While I don't think specifying something proprietary would be a good thing (bad actually -- I would oppose CDP), I just wanted to point out the RELO actually talks about several possible ids, not just CDP.  RELO also mentions MAC address, LLDP (by extension LLDP-MED would be there also), and mentions all in the context of "such as" which I read to mean "for example".  So, I do not surmise that the intent was to propose "proprietary" solution, as alluded below.   The held-identity-extensions draft also talks about LLDP.  In both RELO and held-identity-extensions, in presence of LLDP, I fail to see why the L7 protocol would be used at all in general practice.  If the switching environment supports LLDP / LLDP-MED, then why not use it to directly supply the location objects.  Adding the L7 moving parts would make things less reliable in those cases.  (I can see how there might be cases where L7 is needed, however do not see it for the general rule.  In those cases, supplying these ids may add value.)   -- Peter   "Winterbottom, James" <James.Winterbottom@andrew.com> 08.06.07 19:39               To:        "Henning Schulzrinne" <hgs@cs.columbia.edu>, "GEOPRIV" <geopriv@ietf.org>       cc:               Subject:        RE: [Geopriv]        I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt Hi Henning, I have no concerns about changing the message codes. I am not sure that I see too many issues with the options extension, though as you point out, adding attributes and using their namespace for qualifying them is the norm within XML. I find it hard to believe that you can't see how the identity extensions aren't provided. Please look at http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte nsions-01 It has after all only be presented a couple of time now. This is as opposed to something proprietary like Cisco Discovery Protocolas RELO suggests. Cheers James > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, 9 June 2007 6:26 AM > To: GEOPRIV > Subject: Re: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location- > delivery-00.txt > > We should probably revisit some of the discussions we've had for > LoST, which have led us to abandon the concept of status codes in > favor of "real" XML. I won't repeat the arguments (Andy can chime > in...), but the basic idea was that this makes debugging and > validation easier and seems much more in the spirit of XML. Using > codes that are almost, but not quite, the same as HTTP (or SIP) seems > to be an invitation for confusion or creative extensions where HTTP > codes are "borrowed". > > I'm also unconvinced that creating a non-namespace extensions > mechanism (options) is a good idea. Either we use XML and its tools > or we make up our own protocol, but a hybrid seems dubious > architecturally. IANA can register namespaces, too. > > The editor may want to take a look at the identity mechanisms in > RELO. It is currently not clear how entities are identified and how > this is extensible. > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 16 Jun 2007 10:34:07 -0500

This archive was generated by hypermail 2.1.8 : Sat Jun 16 2007 - 11:34:29 EDT