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

From: [email-masked]
Date: Mon, 26 Jun 2006 16:32:13 -0400 (EDT)

In theory, yes. In practice, the DHCP server is often managed by different
entities than the L2 infrastructure. (This seems to be fairly common on
campuses.)  In our local environment, your approach would be extremely
difficult to implement, without a major network reorganization.

> For the enterprise environment, I would think you would use the DHCP
> relay option, which adds a circuit ID at the switch.  That would be a
> one step map (Circuit ID to location) at the DHCP server.  It's a two
> step configuration (have to assign the circuit ID on the switch, and
> build the circuitId to location map), but still seems to be pretty close
> to what you do with LLDP-MED.
>
> Brian

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 26 Jun 2006 15:56:47 -0400

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 3:19 PM
To: Romascanu, Dan (Dan)
Cc: Rosen, Brian; [email-masked]; [email-masked]
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft
wassubmitted)

I think this is also a matter of implementation complexity. In other  
words, the threshold for an (imaginary) protocol that needs key  
management, an SNMP MIB and an ASN.1 implementation is presumably  
higher than for something like a DHCP option or a simple L2 frame.  
For the case at hand, in many circumstances, configuring a switch  
with basic location information will be easier than doing this  
indirectly through DHCP, as the latter involves a fairly messy "trace  
back" (get MAC address, find which switch port that MAC address  
appears on via various bridge MIB walks, consult wire map database,  
update DHCP database). Two crucial steps in that chain are not  
currently standardized, making working in mixed-vendor environments a  
pain.

We've implemented both a well-known predecessor of LLDP-MED and the  
DHCP option and the former is much easier to implement and more  
reliable.

Thus, I'm in favor of including LLDP-MED.

Henning

On Jun 26, 2006, at 3:09 PM, Romascanu, Dan ((Dan)) wrote:

> Brian,
>
> You are correct that LLDP-MED is well applicable in a bridged  
> (switched) Ethernet environment, although I would avoid saying  
> 'only'. My question is however - how many IP phones are connected  
> to the Internet with an Ethernet switched link being the first link?
>
> I believe that we had a discussion at the start of the ECRIT work  
> about whether enterprise environments have specific requirements  
> that need to be explicitly dealt. At that point in tome we did not  
> find too many obvious examples, but we said something like 'ECRIT  
> will cover enterprise environments, we do not know right now what  
> would be different in the enterprise, but when we'll find something  
> that needs a different solution we shall cove it with the  
> appropriate applicability statement attached'.
>
> I think that the use of a sub-IP protocol like LLDP-MED is one of  
> these cases.
>
> Dan
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: Rosen, Brian [mailto:[email-masked]]
>> Sent: Monday, June 26, 2006 8:41 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp
>> draft wassubmitted)
>>
>> 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/A
> NSI-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
>