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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Jul 2006 09:54:47 -0400

No, but I've proposed that the design team craft an applicability statement for an abstract L7 location acquisition protocol that uses the IP address as the identifier, together with the security implications of it, and ask the AD's (including the security AD's) if that would be acceptable.  That idea seemed to find favor as a way to figure out if the basic idea of using IP address as the identifier will be acceptable, regardless of the protocol details.  I think we will do that work within the next several weeks.

Brian

________________________________

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

Brian,

Can you be more precise on the foreseen "applicability limits" of the yet to be L7 protocol?

 

Guy Caron

Bell Canada

________________________________

De : Rosen, Brian [mailto:[email-masked]] 
Envoyé : 12 juillet 2006 09:21
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft 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

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

---

From: <[email-masked]>
Date: Wed, 12 Jul 2006 10:46:27 -0400

Great!

Therefore those limits are pure speculation at this time and since a brochette of experts will be looking into this, we can be optimistic as of the outcome.

If this is the case, I wonder if all those discussions on a possible list of protocols at the end point would become irrelevant since the L7 protocol would be in a position to work in all IP based network, independent of the L2 on which it is riding on (I admit, this is pure speculation from my part here...).

>From an implementation perspective (this is my primary concern as a broadband access operator AND VoIP service provider in all market segments), this seems to be the most simplified model. However, I wouldn't go as far as restricting one to implement only a protocol; I would say "MUST implement at least the [L7] protocol for location acquisition...". As stated by Barbara, some other business enablers may drive a network administrator to implement another one within its specific environment (the LLDP case) with little incremental efforts and resources.

For the applicability statement you are suggesting, it should apply to all other candidates as well as they too may have limits and security implications.

Guy Caron

Bell Canada

De : Rosen, Brian [mailto:[email-masked]] 
Envoyé : 12 juillet 2006 09:55
À : Caron, Guy (A162859); [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted)

Brian

Brian,

 

Guy Caron

Bell Canada

Brian

Brian, 

11.07.06 20:56 

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

       -andy

*****