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

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

Hi again, 

I think you miss the point I'm trying to make, quite possibly my 
not-so-good wording of it.  Logic I read into Barbara's comment comes to:
   IF config method X is supported, 
      THEN MUST support corresponding location method X, 
   Fallback to L7 if none found. 

In your examples below, if the phone does not support DHCP at all, but 
does support LLDP-MED, it would not implement DHCP location discovery 
(duh) but would also be completely non-functional in any network that only 
provided DHCP configuration (notable example being IPv6 w. address 
autoconfig).  If an enterprise network allows non-sanctioned endpoints (eg 
home devices) to be connected at all, but prefers LLDP for location and a 
bunch of other reasons, then yes, they would need to either i) suffer the 
pain providing both DHCP and LLDP, or ii) simply choose to disallow access 
to those devices without the one method they want to use for location. 
(Remember 802.1X is getting quite pervasive in enterprise, and using LLDP 
it is quite easy to simply not supply a usable VLAN to non -MED / non 
802.1X authorized devices, resulting in effective quarantine.)   Those 
phones that want to be usable in every possible environment would need to 
support all methods. 

I think the result would effectively wind up being the same MUST list, 
since I cannot imagine a phone not implementing DHCP in foreseeable 
future, and also expect LLDP will be effective commercial MUST for 
enterprise (not for non-enterprise, maybe).  However I think it would be 
far easier to maintain as a document process if we can find some way to 
tie support to the configuration methods already used by the device. 

(I also note that the text consumed in this thread is probably now longer 
than code for an LLDP-MED phone implementation.  >;-)

-- Peter

"Rosen, Brian" <[email-masked]>
12.07.06 09:20

        To:     <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, <[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]]
       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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 12 Jul 2006 14:01:33 -0400

Agree that a corporate network can force non-801.1X devices from getting
packet service, which might make LLDP more tractable, but don't forget soft
clients, which would have 802.1X authorizations, but may not have LLDP
support (are their standardized LLDP clients for Windows, for example)?  It
may be possible to get around that problem, but it just makes a requirement
that a PC implement a larger list of protocols than a phone does, and I'm
not sure that such a great idea.

Repeating myself, I think controlling all devices connected to a network is
so hard it will be very uncommon.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 12:45 PM
To: Rosen, Brian
Cc: [email-masked]; [email-masked]
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft
wassubmitted)

Hi again,   

I think you miss the point I'm trying to make, quite possibly my not-so-good
wording of it.  Logic I read into Barbara's comment comes to: 
   IF config method X is supported, 
      THEN MUST support corresponding location method X, 
   Fallback to L7 if none found.   

In your examples below, if the phone does not support DHCP at all, but does
support LLDP-MED, it would not implement DHCP location discovery (duh) but
would also be completely non-functional in any network that only provided
DHCP configuration (notable example being IPv6 w. address autoconfig).  If
an enterprise network allows non-sanctioned endpoints (eg home devices) to
be connected at all, but prefers LLDP for location and a bunch of other
reasons, then yes, they would need to either i) suffer the pain providing
both DHCP and LLDP, or ii) simply choose to disallow access to those devices
without the one method they want to use for location.  (Remember 802.1X is
getting quite pervasive in enterprise, and using LLDP it is quite easy to
simply not supply a usable VLAN to non -MED / non 802.1X authorized devices,
resulting in effective quarantine.)   Those phones that want to be usable in
every possible environment would need to support all methods.   

I think the result would effectively wind up being the same MUST list, since
I cannot imagine a phone not implementing DHCP in foreseeable future, and
also expect LLDP will be effective commercial MUST for enterprise (not for
non-enterprise, maybe).  However I think it would be far easier to maintain
as a document process if we can find some way to tie support to the
configuration methods already used by the device.   

-- Peter 

12.07.06 09:20 

        To:        <[email-masked]> 
        cc:        <[email-masked]>, <[email-masked]>,
<[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 

  _____  

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)

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)

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