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

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 12 Jul 2006 10:53:01 -0500

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: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2006 13:33:52 -0400

On Jul 12, 2006, at 11:53 AM, Stark, Barbara wrote:

> connect to it, and (2) networks where the operator has no control  
> over what connects.
>
> 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.
>

I'm not sure about "most", but I think your estimate of control might  
be slightly idealistic. Many large networks, such as university  
networks, routinely have people plug in essentially random devices.  
We have probably 50,000 such devices on our network, and Columbia is,  
at best, a mid-size university. I suspect that the same is true for  
most school systems and at least some Ethernet VLANs in many  
companies. In many networks, in theory the sys admins has control, in  
practice people still plug in what they like.

Also, Ethernet networks are becoming increasingly popular in multi- 
family residences, such as apartment buildings. From what I hear,  
that model is quite common in South Korea, for example. In general,  
more and more semi-public networks use Ethernet as the access  
technology.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Jul 2006 13:26:55 -0500

We all get different views of how these fit together.  Our enterprise,
which serves a large number of employees (~10,000 from memory) uses a
number of methods to ensure that you can't just plug stuff in.  For
instance, you don't get an IP address unless the networks knows your MAC
address.  I'm sure that this is the sort of thing that Barbara is
talking about - and I am certain that a university is substantially
different to most enterprises.

M

________________________________

From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, 13 July 2006 3:34 AM
To: Stark, Barbara
Cc: Rosen, Brian; [email-masked]
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft
wassubmitted)

 

I'm not sure about "most", but I think your estimate of control might be
slightly idealistic. Many large networks, such as university networks,
routinely have people plug in essentially random devices. We have
probably 50,000 such devices on our network, and Columbia is, at best, a
mid-size university. I suspect that the same is true for most school
systems and at least some Ethernet VLANs in many companies. In many
networks, in theory the sys admins has control, in practice people still
plug in what they like.

Also, Ethernet networks are becoming increasingly popular in
multi-family residences, such as apartment buildings. From what I hear,
that model is quite common in South Korea, for example. In general, more
and more semi-public networks use Ethernet as the access technology.

Henning

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