Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted)

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 26 Jun 2006 13:40:53 -0400

You and I have discussed this, so you know what I'm going to say.

Every phone has to implement every protocol on the list.  The bar for a protocol to be on the list should be very high.  LLDP-MED is only appropriate in a switched Ethernet environment, which is of course, very common in enterprise.   Wherever you could deploy LLDP-MED, it would be reasonable to deploy the DHCP solution.  The reverse is not true.  Claiming it's easier to deploy is interesting, but I don't think it gets above the bar.

Brian

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 1:33 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted)

Brian, list,   

> ... I think we want to have a discussion on whether LLDP-MED is on that list. 

As might be expected, I definitely support LLDP-MED as one on that list of location methods.  Some key points in favour I believe are:   

o LLDP-MED works at Layer 2, which is where real location comes from.  Closest to source is better.   

o Access network elements (L2 switches typically) need to be configured anyway, and while the admin is touching them, location can be entered readily.   

o Wire map associated with L2 access needs to be created and maintained anyway.  (DHCP method would require it to be put in a different, possibly unrelated dB.)   

o Simple and direct, no intermediate mechanisms needed. (Eg. no need to turn on DHCP relay, insert DHCP relay agent sub-options, etc.)  Less dependancies is better.     

o No need for any additional interfaces in LLDP-MED method -- all interfaces are already defined.  In DHCP method (and presumably L7 also ?) an interface to DHCP server, to interface to the wiremap dB, would need to be defined to have a fully standards-based approach.   (In LLDP-MED, the wiremap dB interface is effectively done through SNMP and the defined MIBs, and the data becomes distributed across the L2 infrastructure.)   

o Can be made to work with wireless mobility as well.  Currently, LLDP-MED can locate down to the Access Point only (since the wireless environment does not yet have a standard way to do triangulation or similar), however would be relatively straight-forward to extend to higher accuracy.  (DHCP is completely inappropriate for wireless mobility IMHO.)   

Personally, I think above points make best case to use LLDP-MED in a managed enterprise environment.  That's a BIG market segment!  Other methods may be more appropriate in different environments.   

BTW for those not familiar, among many other things, LLDP-MED provide an L2 mechanism for location conveyance, 100% data compatible by design with the DHCP methods (both geolocation and civic).  The spec, (formally ANSI/TIA-1057), can be found at: 
  http://www.tiaonline.org/standards/technology/voip/documents/ANSI-TIA-1057_final_for_publication.pdf 

Cheers, 
Peter Blatherwick 

"Rosen, Brian" <[email-masked]> 
26.06.06 10:13 
        
        To:        <[email-masked]> 
        cc:         
        Subject:        [Ecrit] New phonebcp draft was submitted

I submitted an update to the phonebcp draft before the deadline.  I incorporated nearly all of the changes suggested on the list.  I did not add a lot of wording about frequency of calls from mobiles as suggested by James.  I also did not delete the section on specific protocols phones must implement for location acquisition as suggested by Patty.  I'll bring up that issue at the meeting; basically, I believe we must have a list that all phones must implement, and access network must choose one from that list.  Otherwise, we will have no interoperability.  The list at present would be DHCP and the L7 protocol (HELD or whatever).  I think we want to have a discussion on whether LLDP-MED is on that list.

Until it appears in the archives, you can find it at:
http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.txt
http://www.brianrosen.net/internet-drafts/draft-rosen-ecrit-phonebcp-01.html

Brian

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: [email-masked]
Date: Fri, 30 Jun 2006 10:48:31 -0400

Hi Rohan,

> LLDP-MED does not work in an 802.11 wireless LAN environment.  The 
assumptions 
> made in LLDP-MED about link reliability, authentication, bandwidth 
availability, timing, 
> and lack of mobility are grossly inappropriate in a WLAN environment. 

Actually, LLDP-MED can be used in WLAN scenarios for location, with the 
constraint that it can only locate to the AP today.  See LLDP-MED spec, 
Annex C for discussion of this.  At this point in time, there is no 
solution in WLAN to resolve closer than the AP.  To your points... If the 
wireless link becomes unreliable, then all methods are off.  Auth is not 
really a strong requirement (IMHO) in this scenario, at least in 
enterprise.  And, bw availability & timing are non-issues due to the very 
small size and periodic advertisements inherent in LLDP -- the other 
proposed methods use more bw and/or have difficulty getting updates on the 
fly.  (Don't understand what you mean by "lack of mobility".)  Yes, an 
imperfect solution, however reasonably practical at this time. 

> I am personally much more interested in location (emergency and otherwise) 
for wireless 
> LAN devices than for wired devices.  The user of a wireless LAN device 
is much less 
> likely to know their own location than a user of a wired LAN devices. 
This is a fast 
> growing market segment because people want mobility once the price is 
right and the 
> quality is good enough.  Yes, we need to solve wired location, but lets 
not forget the 
> wireless communities. 

I both agree and disagree here.  Wired ethernet is by far the dominant 
case today in enterprise scenarios, therefore this is the biggest interest 
for me at this point in time.  LLDP-MED is already being supported by 
several vendors in enterprise space, and is proving to be pretty easy to 
work with, so makes a good choice there IMHO.   Of course I do very much 
agree we need to fully solve WLAN also, both enterprise and public, 
however it is lagging in large part due to lack of a well agreed / 
standardized method of doing the actual location (triangulation or 
otherwise).  The work is ongoing, but will take time. 

Thanks for aiming at the IEEE work.  I was aware, but have not been able 
to keep up with it in detail.  If I understand correctly (may be dubious) 
it appears that yet a 4th location method might be required to support 
this.  (I can hear Brian groaning as I type ;-)

-- Peter

"Rohan Mahy" <[email-masked]>
29.06.06 18:29

        To:     "[email-masked]" <[email-masked]>
        cc:     "Rosen, Brian" <[email-masked]>, [email-masked]
        Subject:        Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted)

Hi Peter,

Some comments inline.  To be clear, I do not have a strong feeling about 
what does on Brian's list or not.  I think LLDP-MED is a completely 
reasonable thing for a wired phone vendor to implement on enterprise class 
phones. 

On 6/26/06, [email-masked] <[email-masked] > wrote:
Brian, list,   

> ... I think we want to have a discussion on whether LLDP-MED is on that list. 

As might be expected, I definitely support LLDP-MED as one on that list of 
location methods.  Some key points in favour I believe are:   

o LLDP-MED works at Layer 2, which is where real location comes from. 
Closest to source is better. 

...As opposed to working at the application layer, where real application 
security comes from.  Closer to the application is better?   I don't want 
to have a debate about layer 2 vs. layer 7 location here, just point out 
that the answer you get depends on what you are willing to tradeoff. 

o Access network elements (L2 switches typically) need to be configured 
anyway, and while the admin is touching them, location can be entered 
readily.   

o Wire map associated with L2 access needs to be created and maintained 
anyway.  (DHCP method would require it to be put in a different, possibly 
unrelated dB.) 

I'll point out that in the wireless case, the location of the station is 
also often in an unrelated place to the the L2 access device. 

o Simple and direct, no intermediate mechanisms needed. (Eg. no need to 
turn on DHCP relay, insert DHCP relay agent sub-options, etc.)  Less 
dependancies is better.     

o No need for any additional interfaces in LLDP-MED method -- all 
interfaces are already defined.  In DHCP method (and presumably L7 also ?) 
an interface to DHCP server, to interface to the wiremap dB, would need to 
be defined to have a fully standards-based approach.   (In LLDP-MED, the 
wiremap dB interface is effectively done through SNMP and the defined 
MIBs, and the data becomes distributed across the L2 infrastructure.)   

o Can be made to work with wireless mobility as well.  Currently, LLDP-MED 
can locate down to the Access Point only (since the wireless environment 
does not yet have a standard way to do triangulation or similar), however 
would be relatively straight-forward to extend to higher accuracy.  (DHCP 
is completely inappropriate for wireless mobility IMHO.) 

LLDP-MED does not work in an 802.11 wireless LAN environment.  The 
assumptions made in LLDP-MED about link reliability, authentication, 
bandwidth availability, timing, and lack of mobility are grossly 
inappropriate in a WLAN environment. 

IEEE 802.11 Task Group V is working on a Layer 2 approach of their own, 
which is significantly better than LLDP-MED on these regards:

ftp://ieee:[email-masked]/11/06/11-06-0010-01-000v-location-presentation.ppt
ftp://ieee:[email-masked]/11/06/11-06-0009-03-000v-location-proposal.doc 
 
There were still some big issues in the posted version.  I provided a 
bunch of comments to one of the authors after that version was published, 
at the last 802.11 interim.  I would expect the draft will be updated 
shortly before the next 802.11 plenary in San Diego (the week after IETF 
66).

Personally, I think above points make best case to use LLDP-MED in a 
managed enterprise environment.  That's a BIG market segment!  Other 
methods may be more appropriate in different environments. 

I am personally much more interested in location (emergency and otherwise) 
for wireless LAN devices than for wired devices.  The user of a wireless 
LAN device is much less likely to know their own location than a user of a 
wired LAN devices.  This is a fast growing market segment because people 
want mobility once the price is right and the quality is good enough. Yes, 
we need to solve wired location, but lets not forget the wireless 
communities. 

thanks,
-rohan