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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Jul 2006 13:55:21 -0400

I think the number of cases where a network operator can control the
specification of all devices connected to the network is vanishingly
small, but it's possible.  Your example is a bad one, I think, because
while the IT guys may be unhappy, people do it all the time, and it's
gotta work.  It's pretty tough to actively prohibit that kind of thing.

The language that a network that CAN control the spec can use any
protocol it wants holds, and LLDP-MED could be a choice for such
networks.  That would not have LLDP mentioned in the -phonebcp document.
Such networks can use ANY protocol, and I don't see a point in providing
recommendations.

Your fundamental suggestion that you implement the location protocol
associated with the configuration mechanism won't work for "open"
networks as you define them.

Brian

________________________________

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 11:53 AM
To: Rosen, Brian; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was
submitted)

I think I'm starting to understand where we're losing each others'
viewpoints.

We have the 2 basic types of networks (as defined in the BCP): (1)
networks where the operator can specify what devices are allowed to
connect to it, and (2) networks where the operator has no control over
what connects.

Enterprise networks are generally the former. I know my corporate
network guys would be extremely upset if I brought in a VoIP phone from
home and tried to connect it through the corporate network. I think it's
reasonable to suggest that an enterprise may choose to implement LLDP in
its network, and would have the ability to require that all devices that
connect to that network must also support LLDP. For devices intended to
operate in these closed enterprise networks, LLDP is definitely an
option. If vendors make CPE intended for these networks, and if the
vendor implements LLDP, I think it's reasonable for this BCP to
recommend that such LLDP-capable devices also do the LLDP-MED Location
identification.

But for open networks, where any device that a consumer buys is expected
to work (home networks behind broadband connections, small biz networks,
hotspots), I don't think LLDP is viable at this time. I think Brian is
right that hotels and hotspots and metropolitan mesh WiFi networks
cannot expect devices to support LLDP, and therefore must implement
either the DHCP or L7 mechanism. If they must implement one of these 2,
then it makes no sense to suggest that they might do LLDP in addition to
one of the others, just in case a device came along that could do
LLDP-MED. If that device is truly intended to work in that open network,
then it would also be able to do DHCP and L7. So why go to the extra
work to do LLDP in the network?

So, I think that the statement about "If LLDP, then LLDP-MED Location ID
is MUST" is completely applicable to devices intended for "closed"
networks, but not "open" networks. The BCP already has verbiage that
indicates devices intended for these different types of networks might
have different requirements. I think we need to expand that and have
clear lists of recommendations for devices on "closed" networks (where
the operator still wants to use open standards), and for those intended
to be connected through "open" networks. 

Barbara

	-----Original Message-----
	From: Rosen, Brian [mailto:[email-masked]]
	Sent: Wednesday, July 12, 2006 9:21 AM
	To: [email-masked]
	Cc: [email-masked]; Stark, Barbara; [email-masked];
[email-masked]
	Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp
draft wassubmitted)

	This thinking results in cases where assumptions made by one end
don't match assumptions made by the other.

	Let's take LLDP as the example.  Barbara would say that if the
phone implements LLDP, then it should implement LLDP-MED.  Okay, so
suppose I have a residential phone which does not implement LLDP, so it
doesn't implement LLDP-MED.  So far, so good.  Now, let's look at an
enterprise network.  It may implement LLDP, and thus LLDP-MED.  Okay,
the enterprise phone on the enterprise network works.  What happens when
the residential phone connects to the enterprise network?  No location.
Let's keep going.  Suppose the residential phone implements DHCP, and
thus implemented the DHCP location options.  Unless the network ALSO
implements DHCP location, it doesn't work.  But if the enterprise
implements the DHCP mechanism, then the LLDP mechanism is superfluous. 

	Now take the enterprise phone and plug it into a home network,
on an access network that does not meet the applicability statement of
the L7 mechanism.  That network deploys DHCP location.  The enterprise
phone can't get location unless it also implements DHCP.  Now take that
same phone and plug it into a network that doesn't deploy DHCP but does
meet the applicability statement for the L7 protocol.  The enterprise
phone ALSO has to implement the L7 protocol.

	The "implement the location mechanism corresponding to the
configuration mechanism" simply does not work.  You need a list, where
one end implements ALL and the other end implements "at least one of" to
get interoperability.  There is no other way.

	It is not the case that the L7 mechanism can be the single
fall-back mechanism.  It will have an applicability limit, and not all
networks will meet it.  This is effectively true of DHCP.  It would be
true of LLDP if it was on the list.  It is the reason why, in this case,
it is the CLIENT that must implement ALL and the server implement one
of.  Usually, we have the server taking the "all" role and the client
taking the "at least one of" role.

	Brian

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Wednesday, July 12, 2006 8:05 AM
	To: Rosen, Brian
	Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
	Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp
draft wassubmitted)

	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. 
	
	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]
<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

*****

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. 118

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

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Jul 2006 21:28:24 +0200

>I think the number of cases where a network operator can control the specification of all devices connected to the network is >vanishingly small, but it's possible.
 
But having said that, I cannot imagine that device manufacturers are developing devices especially for these
type of networks. Most devices are general purpose and may be attached to any network anyway.
 
of course I agree what Ted said:
 
>My agreement with this depends a lot on what "possible" means.  If someone defines a pppoe mechanisms, implementing it in >a phone that doesn't support ethernet or pppoe is  not useful.  If you define that as "not a possible mechanism for that phone", >then we're probably okay. 
 
If the device does not support ethernet or PPPoE, it does also not need to have a location procedure for it.
 
Richard

Von: Rosen, Brian [mailto:[email-masked]]
Gesendet: Mi 12.07.2006 19:55
An: Stark, Barbara; [email-masked]
Cc: [email-masked]
Betreff: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

I think the number of cases where a network operator can control the specification of all devices connected to the network is vanishingly small, but it's possible.  Your example is a bad one, I think, because while the IT guys may be unhappy, people do it all the time, and it's gotta work.  It's pretty tough to actively prohibit that kind of thing.  

The language that a network that CAN control the spec can use any protocol it wants holds, and LLDP-MED could be a choice for such networks.  That would not have LLDP mentioned in the -phonebcp document.  Such networks can use ANY protocol, and I don't see a point in providing recommendations.

Your fundamental suggestion that you implement the location protocol associated with the configuration mechanism won't work for "open" networks as you define them.

Brian

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

I think I'm starting to understand where we're losing each others' viewpoints.

We have the 2 basic types of networks (as defined in the BCP): (1) networks where the operator can specify what devices are allowed to connect to it, and (2) networks where the operator has no control over what connects.

Enterprise networks are generally the former. I know my corporate network guys would be extremely upset if I brought in a VoIP phone from home and tried to connect it through the corporate network. I think it's reasonable to suggest that an enterprise may choose to implement LLDP in its network, and would have the ability to require that all devices that connect to that network must also support LLDP. For devices intended to operate in these closed enterprise networks, LLDP is definitely an option. If vendors make CPE intended for these networks, and if the vendor implements LLDP, I think it's reasonable for this BCP to recommend that such LLDP-capable devices also do the LLDP-MED Location identification.

But for open networks, where any device that a consumer buys is expected to work (home networks behind broadband connections, small biz networks, hotspots), I don't think LLDP is viable at this time. I think Brian is right that hotels and hotspots and metropolitan mesh WiFi networks cannot expect devices to support LLDP, and therefore must implement either the DHCP or L7 mechanism. If they must implement one of these 2, then it makes no sense to suggest that they might do LLDP in addition to one of the others, just in case a device came along that could do LLDP-MED. If that device is truly intended to work in that open network, then it would also be able to do DHCP and L7. So why go to the extra work to do LLDP in the network?

So, I think that the statement about "If LLDP, then LLDP-MED Location ID is MUST" is completely applicable to devices intended for "closed" networks, but not "open" networks. The BCP already has verbiage that indicates devices intended for these different types of networks might have different requirements. I think we need to expand that and have clear lists of recommendations for devices on "closed" networks (where the operator still wants to use open standards), and for those intended to be connected through "open" networks. 

Barbara

	-----Original Message-----
	From: Rosen, Brian [mailto:[email-masked]]
	Sent: Wednesday, July 12, 2006 9:21 AM
	To: [email-masked]
	Cc: [email-masked]; Stark, Barbara; [email-masked]; [email-masked]
	Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

	This thinking results in cases where assumptions made by one end don't match assumptions made by the other.

	Let's take LLDP as the example.  Barbara would say that if the phone implements LLDP, then it should implement LLDP-MED.  Okay, so suppose I have a residential phone which does not implement LLDP, so it doesn't implement LLDP-MED.  So far, so good.  Now, let's look at an enterprise network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let's keep going.  Suppose the residential phone implements DHCP, and thus implemented the DHCP location options.  Unless the network ALSO implements DHCP location, it doesn't work.  But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous. 

	Now take the enterprise phone and plug it into a home network, on an access network that does not meet the applicability statement of the L7 mechanism.  That network deploys DHCP location.  The enterprise phone can't get location unless it also implements DHCP.  Now take that same phone and plug it into a network that doesn't deploy DHCP but does meet the applicability statement for the L7 protocol.  The enterprise phone ALSO has to implement the L7 protocol.

	The "implement the location mechanism corresponding to the configuration mechanism" simply does not work.  You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability.  There is no other way.

	It is not the case that the L7 mechanism can be the single fall-back mechanism.  It will have an applicability limit, and not all networks will meet it.  This is effectively true of DHCP.  It would be true of LLDP if it was on the list.  It is the reason why, in this case, it is the CLIENT that must implement ALL and the server implement one of.  Usually, we have the server taking the "all" role and the client taking the "at least one of" role.

	Brian

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, July 12, 2006 8:05 AM
	To: Rosen, Brian
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

	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 

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)
	
	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] <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

*****

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. 118