Re: [Softwires] WGLC on draft-ietf-softwire-unified-cpe-03

Hi Ole,

Thanks for the comments. Please see inline.

Cheers,
Ian

> On 15 Apr 2016, at 10:41, otroan@employees.org wrote:
> 
> Here are my comments from a quick glance. Apologies for being late.
> 
> Thanks for simplifying this document.
> A much easier and less contentious read now.
> 
> I think it needs a little bit more detail and explanation before advancing though.
> 
> The document is lacking some detail. It mentions "DHCPv6 Offer", which in 3315 terminology I'm not sure what is.
> In a 4-way DHCPv6 exchange, would the expectation be something like:
> 
> -> SOLICIT:  ORO includes MAP-E, LW46, and DS-lite and Priority option request.
> <- ADVERTISE : includes priority option, with MAP-E, DS-lite and LW46 data objects (server might have reserved address at this point)
> -> REQUEST: client only request the mechanism at the top of the list
> <- REPLY: server assigns the addresses to client, and can free up resources reserved for the other mechanisms.

[if - Good catch on the ‘offer’. Will update.

For the proposed message flow and corresponding server side actions, there is no dynamic on demand assignment of DHCP managed resources being made for any of these mechanisms, with the exception of DHCPv4oDHCPv6 provisioning. DS-lite only dynamically allocates any resources used for CGN44 at the AFTR when a client 4in6 outgoing request is made. MAP & lw4o6 using RFC7598 both require the DHCP server to be pre-configured and there is no pool based allocation that resources are taken from or returned to.

DHCPv4oDHCPv6 can make dynamic pool allocations, but unless the client implemented this and used it for its provisioning, then a lease would never be made.]

> 
> If I was an operator that had a fixed allocation of address 1.1.1.1:1000-2000 to a given customer. Would I then put the same IPv4 address for each of the mechanisms in the ADVERTISE?

[if - That’s really a deployment choice. Certainly, there’s no reason why the provisioning mechanism couldn’t supply either the same or different addressing allocations to the client, but from a BR functionality and routing perspective it’s unlikely that you would be able to do this - the BR would have to be running at least two BR mechanisms in parallel and have a way of identifying which particular mechanism a client was using. Could be hard for ingress traffic on a MAP-E/T BR for example.

We can add some text discussing this point.]

> 
> Do you need to say anything about how to deal with clients that do not support the priority option?

[if - This would require server side logic to evaluate the softwire option codes in the ORO supplied by the client and provision a single mechanism based on server side policy. However, as one of the main points of writing this draft in the first place is to avoid having to do this (for complexity and scalability reasons), I would suggest that the text could describe this with the drawbacks and without adding any requirements to implement this functionality.]

> 
> Cheers,
> Ole
> 
> 
> 
> 
>> On 22 Mar 2016, at 07:55, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:
>> 
>> Hi folks,
>> 
>> The authors of draft-ietf-softwire-unified-cpe-03 believe this document is ready for advancement.
>> We would like to issue a working group last call starting from today to April 5th.
>> 
>> Please send your substantial comments to the list during the last call. You are also welcome to send your editorial comments directly to the authors.
>> 
>> Thanks for reviewing the draft.
>> 
>> 
>> Yong Cui, Suresh Krishnan and Ian Farrer
>> 
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> 