Re: [dhcwg] Opsdir last call review of draft-ietf-dhc-dhcpv6-yang-24

[[e-mail]]

Hi Will,

Thanks for your comments and my apologies for the length of time that it’s taken me to reply.

Regarding your suggestion for running the server on specific interfaces or IP addresses and making an assignment decisions based on that, the way that the example YANG modules would handle this is as follows.

Interface / listener address & port is configured via the following portion of example-dhcpv6-server-conf.yang:

                                                             
      leaf ipv6-listen-port {                                           
        type uint16;                                                    
        default 547;                                                    
        description                                                     
          "UDP port that the server will listen on.";                   
      }                                                                 
      choice listening-interfaces {                                     
        default all-interfaces;                                         
        description                                                     
          "Configures which interface or addresses the server will         
          listen for incoming messages on.";                            
        case all-interfaces {                                           
          container all-interfaces {                                    
          presence true;                                                
          description                                                   
            "Configures the server to listen for incoming messages         
            on all IPv6 addresses (unicast and multicast) on all of        
            its network interfaces.";                                   
          }                                                             
        }                                                               
        case interface-list {                                           
          leaf-list interfaces {                                        
            type if:interface-ref;                                      
            description                                                 
              "List of interfaces on which the server will listen for   
              incoming messages. Messages addressed to any              
              valid IPv6 address (unicast and multicast) will be        
              received.";                                               
          }                                                             
        }                                                               
        case address-list {                                             
          leaf-list address-list {                                      
            type inet:ipv6-address;                                     
            description                                                 
              "List of IPv6 address(es) on which the server will        
              listen for incoming DHCPv6 messages.";                    
          }                                                             
        }                                                               
      }                                                                 
      leaf-list interfaces-config {                                     
        type if:interface-ref;                                          
        default "if:interfaces/if:interface/if:name";                   
        description                                                     
          "A leaf list of interfaces on which the server should         
          listen.";                                                     
      }   


Making address/prefix assignments based on the interface/address that a request is received on is treated as a class-selection function (along with other address/prefix selection criteria). The following portion of 
Example-dhcpv6-class-select.yang would do this:


     case received-interface-id {                                      
        description                                                     
          "Client class selection based on the incoming interface          
          of the DHCPv6 message.";                                      
        leaf received-interface {                                       
          type if:interface-ref;                                        
          description                                                   
            "Reference to the interface entry for the incoming          
            DHCPv6 message.";                                           
        }                                                               
      }                                                                 
      case packet-source-address-id {                                   
        description                                                     
          "Client class selection based on the source address of        
          the DHCPv6 message.";                                         
        leaf packet-source-address {                                    
          type inet:ipv6-address;                                       
          mandatory true;                                               
          description                                                   
            "Source address of the DHCPv6 message.";                    
        }                                                               
      }                                                                 
      case packet-destination-address-id {                              
        description                                                     
          "Client class selection based on the destination address         
          of the DHCPv6 message.";                                      
        leaf packet-destination-address {                               
          type inet:ipv6-address;                                       
          mandatory true;                                               
          description                                                   
            "Destination address of the DHCPv6 message.";               
        }                                                               
      }                                

Does this address your comment?

Thanks,
Ian

> On 16. Dec 2021, at 08:05, Liushucheng (Will LIU, Strategy & Industry Development) <[e-mail]> wrote:
> 
> Dear Ian,
> 
> Sorry for being late. 
> Thanks for your reply. I had a long discussion on with several people to try to provide some content example. My reply inline with  [Will].
> 
>> -----Original Message-----
>> From: [e-mail] <mailto:[e-mail]> [mailto:[e-mail] <mailto:[e-mail]>]
>> Sent: Friday, November 19, 2021 3:18 PM
>> To: Liushucheng (Will LIU, Strategy & Industry Development)
>> <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
>> [e-mail] <mailto:[e-mail]>
>> Subject: Re: Opsdir last call review of draft-ietf-dhc-dhcpv6-yang-24
>> 
>> Hi Will
>> 
>> Many thanks for your review and comments. Please see inline below.
>> 
>> Best regards,
>> Ian
>> 
>>> On 18. Nov 2021, at 10:37, Will LIU via Datatracker <[e-mail]>
>> wrote:
>>> 
>>> Reviewer: Will LIU
>>> Review result: Has Nits
>>> 
>>> Hi all,
>>> 
>>> I have reviewed draft-ietf-dhc-dhcpv6-yang-24 as part of the
>>> Operational directorate's ongoing effort to review all IETF documents
>>> being processed by the IESG.  These comments were written with the
>>> intent of improving the operational aspects of the IETF drafts.
>>> Comments that are not addressed in last call may be included in AD
>>> reviews during the IESG review.  Document editors and WG chairs should
>>> treat these comments just like any other last call comments.
>>> 
>>> “This document describes YANG data modules for the configuration and
>>>  management of DHCPv6 (Dynamic Host Configuration Protocol for IPv6
>>>  RFC8415) servers, relays, and clients.”
>>> 
>>> My overall view of the document is 'Has Nits'.
>>> 
>>> ** Technical **
>>> 
>>> Page54,
>>> 1. The DHCPv6 server may be bound to an interface to specify the
>>> DHCPv6 address pool of the corresponding interface.
>> 
>> [if - Interface configuration and binding the server function to specific
>> interfaces/addresses is not covered in the ietf-dhc6-server module. There is a
>> lot of variance in the way that individual implementations configure this (e.g.
>> server/router/BNG), and also the class-selection logic that defines how an
>> individual request’s address/prefix pool and options are selected that this best
>> left to the implementor to define implementation specific YANG to cover these
>> areas.
>> 
>> Examples of vendor specific configuration modules for the server’s base
>> configuration and class-selector logic are given in Appendixes C & D.
>> ]
> 
> [Will] Agree this is not covered in the module and a lot of variance exist. After checking the examples in Appendix, there is no example about DHCPv6 server bounding to an interface to specific interfaces/addresses, may I suggest add a short example like below?
> 
> augment /if:interfaces/if:interface {
>    description
>      "Extend interface attribute.";
>    container dhcpv6-server-attribute {
>      description
>        "Configure DHCPv6 server interface function.";
> 
>      choice server-mode {
>        description
>          "Set dhcpv6 server mode in the Interface.";
>        case automatic-enable {
>          description
>            "Enable/disable dhcpv6 server automatic mode.";
>          leaf server-automatic-anable {
>            type boolean;
>            default "false";
>            description
>              "Enable/disable dhcpv6 server automatic mode.";
>          }
>        }
>        case pool-name {
>          description
>            "Pool name.";
>          leaf pool-name {
>            type string {
>              length "1..31";
>            }
>            description
>              "Pool name.";
>          }
>        }
>      }
>      leaf is-allow-hint {
>        type boolean;
>        default "false";
>        description
>          "Enable/disable to allow the server to assign prefix according to the client expectation.";
>      }
>      leaf preference {
>        type uint8 {
>          range "0..255";
>        }
>        default "0";
>        description
>          "The server priority in the advertise packet.";
>      }
>      leaf is-rapid {
>        type boolean;
>        default "false";
>        description
>          "Enable/disable to support for fast allocation.";
>      }
>      leaf is-unicast {
>        type boolean;
>        default "false";
>        description
>          "Enable/disable to specify the unicast communication between client and server in the address renewal process.";
>      }
> }
> 
>> 
>>> 2. The key of container address-pools and container prefix-pools in
>>> the DHCPv6 server may be changed to pool-name.
>> 
>> [if - ‘pool-id’ was originally typed as being uint32 with the intention that it
>> was just a unique ID number for the pool. The type got changed to string due
>> to a recent review comment, But I think the intended use remains the same - it
>> is a unique identifier for the pool, whether the user choses a numeric or a
>> string based identifier as suits their requirements.
>> 
>> My feeling is that pool-id is a suitable name for this function, but would be
>> happy to change if there is a good reason to use pool-name.
>> ]
>> 
> [Will] Agree to change 'pool-id’ to string. 
> 
> Regards, 	|   致礼! 
> Will LIU  	|   刘树成
> 
>>> 
>>> ** Editorial **
>>> 
>>> No.
>>> 
>>> Regards,
>>> Will (Shucheng LIU)