Minutes IETF98: dhc

Meeting Minutes Dynamic Host Configuration (dhc) WG
Title Minutes IETF98: dhc
State Active
Other versions plain text
Last updated 2017-04-08

Meeting Minutes

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

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

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

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)

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