Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

["Hemant Singh (shemant)" <[e-mail]>]

Ole,

General comment.  Some folks would have liked to LastCall rfc6204bis during December 2011.  Rfc6204bis now seems to be in a mode such as the mode the ipv6 node-requirement document was in.  The ipv6 node-requirement document will always miss something that someone wants but the document is not held back after a certain set of requirements are in.  Most issues raised below have been beaten to death and we still have no resolution on the issues.  It's up to the WG to decide how long should rfc6204bis wait and punt to rfc6204ter?  See in line below.

I will reply on the PCP and draft-dupont in another email so that the comments do not get cluttered in this CE router discussion.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ole Trøan
Sent: Friday, March 09, 2012 6:51 AM
To: [e-mail] WG
Cc: [e-mail] Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>Major:
>======

>1. The DHCP "problem".
>   UNH testing uncovered quite a few issues with the 3315/3633 protocol specifications with
>   regards to support for both IA_NA and IA_PD. these issues are debated in DHC and there will be a DHC
>   bar/DT meeting to see if those issues can be resolved and how. 6204bis depends on the outcome of this and
>   shouldn't proceed before we know what requirements to make on DHCP.
>   This is a problem we need to solve, and I don't think we can be silent on it.
>   (e.g. bis has removed 6204, W-5. this also affects WPD-6.)
>   Suggestion: Await resolution in DHC and adopt requirements accordingly.

Waited for three months now having contacted the DHC WG with the issues.  Actually it's more than three months because the issues were known to some DHC experts who are also on the cpe router design team.  There is still no resolution.   Why wait? A rfc6204ter can cover the DHC solutions when the solutions become available.  Alternatively, when rfc6204bis is in the IESG, if DHC has any resolution, one could incorporate the changes.

>3. Section 4.4.1: transition mechanisms for IPv6. in introducing 6rd, 
>   a CE might end up being multi-homed. that opens up
>   a can of worms that the draft is silent on. either include the requirements from
>   draft-townsley-troan-ipv6-ce-transitioning-02 incorporated or specify that native an 6rd are mutually
>   exclusive.
>   Suggestion: Incorporate requirements from above draft.

The document above will take time to gestate in the IETF.  Unless the document above is an RFC and some working implementations have shown the algorithms of the document working, rfc6204bis cannot do anything about this work.  I would continue rfc6204bis without this work.

>4. life-extension mechanisms for IPv4. firstly I don't think this mechanism belongs in this document, which 
>   is all about delivering IPv6 service, while DS-lite is all about delivering IPv4 service.
>   in addition to creating the same multi-homing issue (now for IPv4) above, it also has missing pieces.
>   e.g. assigning full global addresses, something that is being worked on in softwire. fourthly (have I got
>   that far) there are a number of proposals in softwires for complementary / competing mechanisms for
>   IPv4 life extensions. NAT464, MAP-{T,E}, 4rd-U. there is also SD-NAT which achieves the same, but doesn't
>   use IPv6 transport at all. I would prefer that none of these was in _this_ document, but that we had a separate
>   document for "Life extensions for IPv4 CEs"

We are going down the rathole again trying to label DS-Lite as IPv4 tech but it's beaten to death the issue is debatable.  Life extensions is very IPv4 specific.  The kitchen sink of other new transition tech have to all reach RFC form before any CPE router document can consider them.  Move this work to rfc6204ter.

We can have a Webex meeting to discuss the minor issues raised and then publish the closure to v6ops for further comments.

Hemant