Re: [L3sm] [l3sm] #22 (draft-ltsd-l3sm-l3vpn-service-model): pe-dhcp vs provider-dhcp terminology

Hi Stephane,

Thank you for the accommodation.

Your model with two server addresses is a little bit deeply nested like the followings.

<dhcp-relay>
  <customer-dhcp-servers>
    <customer-dhcp-servers>
      <server-ip-address>192.168.0.1</server-ip-address>
    </customer-dhcp-servers>
    <customer-dhcp-servers>
      <server-ip-address>192.168.1.1</server-ip-address>
    </customer-dhcp-servers>
  </customer-dhcp-servers>
</dhcp-relay>

I prefer removing container customer-dhcp-servers or using leaf-list server-ip-address.
At least, list customer-dhcp-servers should be customer-server.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Monday, September 05, 2016 4:34 PM
To: Ogaki, Kenichi; jplandry@bell.ca
Cc: l3sm@ietf.org
Subject: Re: [L3sm] [l3sm] #22 (draft-ltsd-l3sm-l3vpn-service-model): pe-dhcp vs provider-dhcp terminology

Here is what I added to the model :

identity provider-dhcp-relay {
		base address-allocation-type;
		description
		 "Provider network provides DHCP relay service to customer.";
	}

			container dhcp-relay { # Same for IPv6
					when 
					"../address-allocation-type = 'provider-dhcp-relay'"
					 {
						description
						 "Only applies when 
						 provider is required to implementations
						 DHCP relay function";
					}
					container customer-dhcp-servers {
						list customer-dhcp-servers {
							key server-ip-address;

							leaf server-ip-address {
								type inet:ipv4-address;
								description
								"IP address of customer DHCP server";
							}
							description
							 "List of customer DHCP server";
						}
						description
						 "Container for list of customer DHCP server";
					}
				}

-----Original Message-----
From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi
Sent: Monday, September 05, 2016 03:06
To: jplandry@bell.ca
Cc: l3sm@ietf.org
Subject: Re: [L3sm] [l3sm] #22 (draft-ltsd-l3sm-l3vpn-service-model): pe-dhcp vs provider-dhcp terminology

Hi,

Although the data model uses the term pe-dhcp, I still prefer provider-dhcp, because the case exists that PE just works as a DHCP-relay and DHCP server sits outside PE. This should depend on each provider's implementation.

Meanwhile, if it's allowed at this phase and can make a consensus with other providers, I want to add a dhcp-relay option where a customer deploys own dhcp server and requests PE to relay dhcp messages to the server.
It's our real use case.

text proposal:

   o  dhcp-relay : the customer deploys own DHCP server(s) for their equipments and will request PE to relay DHCP messages to the server(s), this is applicable to both IPv4 and IPv6 addressing.

...
    identity dhcp-relay {
        base address-allocation-type;
        description
         "Customer deployes own DHCP server(s) and requests PE to relay DHCP messages to the server(s).";
    }
...
            container ipv4 { //same as ipv6
                ...
                container dhcp-relay {
                    when "../address-allocation-type = 'dhcp-relay'"
                      {
                         description
                          "Only applies when address allocation type is dhcp-relay"; //not protocol, but address
                     }
                    leaf-list server-address {
                        type inet:ipv4-address;
                        description
                         "Describes the customer's DHCP server address(es)";
                    }                    
                }
                ...
            }

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of l3sm issue tracker
Sent: Saturday, September 03, 2016 2:34 AM
To: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org; jplandry@bell.ca
Cc: l3sm@ietf.org
Subject: [L3sm] [l3sm] #22 (draft-ltsd-l3sm-l3vpn-service-model): pe-dhcp vs provider-dhcp terminology

#22: pe-dhcp vs  provider-dhcp terminology

 Section 5.2.1.2.1 titled "IP addressing" mentions provider-dhcp as one of  the possible IP address allocation scheme. I believe this replaces  deprecated value pe-dhcp since provider-dhcp is nore generic but pe-dhcp  still shows up in other sections of the document.

 identity address-allocation-type {
         description
          "Base identity for address-allocation-type
          for PE-CE link.";
     }
     identity pe-dhcp {
         base address-allocation-type;
         description
          "PE router provides DHCP service to CE.";
     }
     identity static-address {
         base address-allocation-type;
         description
          "PE-CE addressing is static.";
     }
     identity slaac {
         base address-allocation-type;
         description
          "Use IPv6 SLAAC.";
     }

 Additionally, a condition refers to former pe-dhcp in error, I believe the  description should also mention provided-DHCP as opposed to static. This  same error is present in both ipv4 and ipv6 containers.

 leaf number-of-dynamic-address {
                     when
                     "../address-allocation-type = 'pe-dhcp'"
                      {
                         description
                          "Only applies when
                          protocol allocation type is static";
                     }
                     type uint8;
                     default 1;
                     description
                      "Describes the number of IP addresses the
                      customer requires";
                 }

-- 
-------------------------------------+----------------------------------
-------------------------------------+---
 Reporter:  jplandry@bell.ca         |      Owner:  draft-ltsd-l3sm-l3vpn-
     Type:  defect                   |  service-model@tools.ietf.org
 Priority:  trivial                  |     Status:  new
Component:  draft-ltsd-l3sm-l3vpn-   |  Milestone:
  service-model                      |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

Ticket URL: <https://trac.tools.ietf.org/wg/l3sm/trac/ticket/22>
l3sm <https://tools.ietf.org/l3sm/>

_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm

_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm