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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jul 2006 20:56:51 -0400

But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP.  If every access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network.  Ditto an enterprise phone.  Location acquisition has to work always.  If there is a list, and one end must support all, with the other end must support at least one, it always works.  

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
[email-masked]

-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; [email-masked]
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.":
 
If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>. 
   and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>. 
 
Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec.
 
Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and <dhcp-civil>, when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address).
 
Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here.
Barbara

	-----Original Message-----
	From: Andrew Newton [mailto:[email-masked]]
	Sent: Friday, June 30, 2006 9:44 AM
	To: Rohan Mahy
	Cc: Rosen, Brian; [email-masked]
	Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

	On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:

		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. 

	Just throwing in my $0.0199997, I have not formed a strong opinion about this either.  It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses.

	Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

	-andy

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162

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

---

From: [email-masked]
Date: Wed, 12 Jul 2006 07:55:47 -0400

Hi Barbara,

I like the structure of what you are suggesting, and think the same 
general form could apply to other mechanisms as they come along.  Perhaps 
it reduces to "for every configuration method the endpoint supports, there 
MUST be support for the corresponding location method".   Then add some 
more "MUST" details for the ones known at this time.  Right now we have as 
methods: DHCP, LLDP-MED, some sort of L7.  It seems likely there will be 
some WLAN approach as well (which could also be LLDP-MED-based ... but 
lets not reignite debate on yet unknown IEEE decisions).  I doubt we would 
see more any time soon.  Seems manageable. 

And, yes, saying the Location Identification TLVs are MUST for LLDP-MED is 
redundant, but it is certainly worth saying anyway. 

> Anyway, I think both DHCP clients and LLDP-MED need to make it into 
devices based on all their merits, and not just on location discovery.  ...
Agree.  An additional point is that network administrators also make these 
decisions.  The approach used absolutely must match how the network want 
to run their network, or it will either not be turned on at all or 
(perhaps worse) it will be on but maintained as a sideline, leading to 
lowered accuracy and reliability. 

-- Peter

"Stark, Barbara" <[email-masked]>
11.07.06 20:43

        To:     "Andrew Newton" <[email-masked]>, "Rohan Mahy" <[email-masked]>
        cc:     "Rosen, Brian" <[email-masked]>, [email-masked]
        Subject:        RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the 
network operator does not control the specification of every device 
connected to the network.":
 
If the device has a DHCP client, the client MUST support RFC 3825 and 
<dhcp-civil>. 
   and
If the device supports LLDP-MED, it MUST support the "Location 
Identification TLV" as defined in <LLDP-MED reference>. 
 
Given that the Location Identification TLV is mandatory for all VoIP-type 
endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd 
if statement really doesn't say much. But it would also suggest that 
devices that could have soft clients on them (PCs, PDAs) also need to do 
that TLV when they do LLDP-MED. All router-type devices that implement 
LLDP-MED are also required to support this TLV, per the spec.
 
Since I'm really not at all concerned with the behavior of endpoints that 
don't have a DHCP client, I think the first if statement is also 
reasonable. However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it SHOULD 
support being configured to request location through a DHCP INFORM message 
with options as described in RFC 3825 and <dhcp-civil>, when it is 
configured to use one of these alternate bootstrap methods (e.g., PPPoE, 
PPPoA, static IP address).
 
Anyway, I think both DHCP clients and LLDP-MED need to make it into 
devices based on all their merits, and not just on location discovery. If 
a vendor can't justify putting one or the other of these into a device 
(outside of recommendations in this BCP), then I say the protocol doesn't 
belong in the device. If the device is going to have one or the other, or 
both, then it needs to support the location determination mechanism that 
goes with it. Since, for LLDP-MED, that's already a requirement of the 
LLDP-MED spec, I really don't see a problem with stating it here.
Barbara
 
-----Original Message-----
From: Andrew Newton [mailto:[email-masked]]
Sent: Friday, June 30, 2006 9:44 AM
To: Rohan Mahy
Cc: Rosen, Brian; [email-masked]
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

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. 

Just throwing in my $0.0199997, I have not formed a strong opinion about 
this either.  It does seem reasonable for enterprise class devices with 
ethernet jacks to implement LLPD-MED, or for devices of category Y to 
implement method X... as what must be implemented by the device will 
always be dictated by the network media it uses.

Where this gets a little tricky is that if there is no one common method, 
then devices may end up implementing things that are not appropriate in an 
attempt to have devices that work in multiple network environments... and 
even then they may end up missing the mark.  Therefore, one method that 
does work in all environments must be implemented.   And that is likely to 
be the L7-LCP.

-andy
*****
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential, proprietary, and/or 
privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by 
persons or entities other than the intended recipient is prohibited. If 
you received this in error, please contact the sender and delete the 
material from all computers. 162_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: [email-masked]
Date: Wed, 12 Jul 2006 08:04:44 -0400

Brian,
Counter-point to below is that if the device and network do not support 
mutually agreeable configuration method, then the device is a brick 
anyway.  L7 becomes a fall-back for the cases where the direct 
configuration method does not support passing location through (best 
example seems to be home router on DSL or cable modem). 
An important case, not sure well heard yesterday during meeting, was that 
in an IPv6 environment with address autoconfig there may be no DHCP at 
all.  This may or may not be a small case as IPv6 rolls out, remains to be 
seen.  And while IPv6 is not really important now in N.A. it is very 
rapidly becoming important in Asia/Pac and also Australia (I'm told). 
Cannot ignore it. 
-- Peter

"Rosen, Brian" <[email-masked]>
11.07.06 20:56

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

But unless every phone supports LLDP-MED, then an enterprise must also 
implement DHCP (or L7) in order to support those phones that don't support 
LLDP.  If every access network has to support those 2, then LLDP is 
superfelous.

A residential phone may be plugged into an enterprise network.  Ditto an 
enterprise phone.  Location acquisition has to work always.  If there is a 
list, and one end must support all, with the other end must support at 
least one, it always works. 

-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; [email-masked]
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft 
wassubmitted)

        -----Original Message-----
        From: Andrew Newton [mailto:[email-masked]]
        Sent: Friday, June 30, 2006 9:44 AM
        To: Rohan Mahy
        Cc: Rosen, Brian; [email-masked]
        Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp 
draft wassubmitted)

                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.

        Just throwing in my $0.0199997, I have not formed a strong opinion 
about this either.  It does seem reasonable for enterprise class devices 
with ethernet jacks to implement LLPD-MED, or for devices of category Y to 
implement method X... as what must be implemented by the device will 
always be dictated by the network media it uses.

        Where this gets a little tricky is that if there is no one common 
method, then devices may end up implementing things that are not 
appropriate in an attempt to have devices that work in multiple network 
environments... and even then they may end up missing the mark. Therefore, 
one method that does work in all environments must be implemented.   And 
that is likely to be the L7-LCP.

        -andy

*****

material from all computers. 162