Minutes IETF98: dhc
minutes-98-dhc-00

** DRAFT ** DHC WG Minutes for IETF-98 (Chicago, IL USA)

Date: Thursday, March 30, 2017, 17:40-18:40 CDT
Location: Montreux 3
Chairs: Tomek Mrugalski (TM) & Bernie Volz (BV)
Secretary: vacant
Based on Etherpad Minutes recorded by Ian Farrer. Prepared by Bernie Volz.

 1. Co-Chairs - Administrativa (Agenda Bashing, WG Status, ...) - 10 min

 draft-ietf-dhc-rfc3315bis-07 Presentation

 Ted Lemmon (TL) - Sounds like you're saying relay agents should filter any
   packets they don't know
 BV - No quite the opposite. They should not forward 2 message types
 TL - Is there any values?
 BV - That's the question
 TL - Sounds like a new req. with no value
 BV - May be best to be silent about it
 TL - Or you could say may discard

 Francis Dupont (FD) - This morning we discussed a new use for PD in 6man. I
   would like someone to check with 6man that we don't need to change PD for
   use in this next context.
 BV - That work's going to be interesting. Maybe they shouldn't call it PD
   as it's not the same
 FD - As it's not traditional PD, they open the door for problems

 Tim Winters (TW) - I agree we should talk about it. There's things we can
   do to clear it up or we can chase it up and go read all the drafts. We're
   open to making changes.
 BV - And you're on the 3315-bis team
 Suresh Krishnan (SK) - Keep me posted. I want to be involved
 Eric Kline (EK) - Were there changes to make it work on hosts
 BV - There were some changes made to the wording to make it work on hosts
   so that non-router devices could do PD
 EK - PIO-X and PD could exist at the same time

 Fred Templin (FT) - I've been doing PD to hosts for 2 years it works great,
    but to make it secure you need the stuff we're about to talk about
    (secure dhcp)


 2. Discussion of seDHCPv6 and RAAN - Chairs - 10 min
    draft-ietf-dhc-sedhcpv6 (discussion of WGLC issues)
    draft-ietf-dhc-dhcpv6-agentopt-delegate (resume work on this document?)

 TL - I think we should do a 05 version as a WG doc
 FT - I agree with TL
 BV - Any objections?
 No objections raised

Actions: seDHCPv6 will likely not pass WGLC as there were several issues
raised. The RAAN draft should be published (with motivation for why this
work is now important (seDHCPv6).


 3. DHCP option for NSH in SFP, Venkata Subba Rao Gorrepati (VSRG) - 10 min
    draft-ypal-sfc-dhcp-option-for-nsh-for-sfp

 Slide 2
 TL - Can I ask you to expand the acronyms?
 SFF - Service Function Forwarder
 SF - service Function
 NSH - Network Service Header

 Slide 3
 BV - We are just seeing this to evaluate the DHCP. The technology is being
   developed in the SFC WG
 SK - I agree with you Bernie.

 Slide 4
 TL - Can you tell me what the reserved field is for
 VSRG - In case we need it in the future
 TL - If you need a new structure in the future, wouldn't you just define a
   new DHCP option format
 VSRG - We'll check it in the next version

 Slide 6
 XF - I recall there's a WG document for control plane that says the control
   plane sets up the forwarding. What's the relationship/ This SFP control
   plane is not standardized. We don't want to put control plane into the
   data plane.

 TM - How big is the SFP info that will be sent?
 VSRG - The service point information.
 TM - 20 bytes, 50? 100?
 VSRG - Yes. It depends on how many nodes there are
 TM - The biggest option in DHCPv4 can be 255 bytes
 BV - Not correct, we can use concatenation (see RFC 3396)
 TM - True, but if you have to use it you might have other problems

Actions: The Service Function Chaining (SFC) WG should take on this work,
notifying DHC when there are significant changes/WGLC.


 4. DHCP v4 YANG update, Gang Yan (GY) - 10 min
    draft-liu-dhc-dhcp-yang-model

 Ian Farrer (IF) - Have you modelled all of the options which are
  available? We had a lot of discussion about this for the DHCPv6 YANG draft
  and have modelled all of the current options. It would make sense to align.
 GY - We can talk offline

 TM - I don't think you need to worry too much about new messages in DHCPv4!

 BV - Should we adopt or leave as an individual submission?
 No comments
 BV - We'll leave it as an individual submission for now

Actions: None. The authors are encouraged to continue this work (and follow
up on the options issue per the DHCPv6 Yang model). The WG will continue to
focus on the DHCPv6 Yang model for now.


 5. Multi-requirement Extensions for DHCPv6, Lin He (LH) - 10 min
    draft-ren-dhc-mredhcpv6-00

 Jinmei Tatya (JT) - About slide 4 - This is not the main issue but to
   clarify, I don't think NS messages are forwarded by routers. It's a single
   link protocol.  If you're saying that DAD is not very scalable, that's
   probably true though.
 EK - Broadly, I think this is a bad idea for the RAs. If you're using SLAAC
   then you don't have any business telling people how to create an address.
   Also, you need to take it to 6man
   The ND exhaustion attack should be solved at L3

 EK - I also wanted to say that client's with autoconfigured address could
   register it. It was suggested by SK and was shot down by BV saying that
   DHCP is not a logging protocol.
 SK - I wrote that draft. You would use some kind of logging protocol - if
   you're going to register your DNS name, you can register your address.
   You need to take it to 6man. I think the DHCP part of this is suspect.

Actions: None. If this work continues, it would require taking it to 6man
and perhaps other WGs.


And additional presentation was added to the agenda:

 6. DHCPv6 Options for Discovery of NAT64, Jordi Palet (JP)
    draft-li-intarea-nat64-prefix-dhcp-option-01

 EK - Personally, I think if you've reached this point, have you designed the
   network wrong? It seems complicated and obscure.
 JP - We see this as being necessary in many different scenarios. I think
   this way is simpler
 EK - Is there a document describing how you've solved these problems?
 JP - Workarounds for 3-5000 customers, but for bigger networks, it won't
   scale.
 EK - If you need all this NAT64, you're not moving away from v4
 Simon Perrault (SP) - We already have a NAT64 discovery mechanism. Why
   doesn't that work?
 JP - Slide 2 - It's for different v4 destinations. It's in the draft.

Actions: None. This was informational as this work is being done in the
IntArea WG.