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

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2016 20:32:08 +0200 (CEST)

On Tue, 22 Mar 2016, Yong Cui 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.

I have re-read this draft and I support it and it's my opinion that it's 
useful and should proceed.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 6 Apr 2016 19:23:05 +0000

> On 06 Apr 2016, at 20:32, Mikael Abrahamsson <[email-masked]> wrote:
>
> I have re-read this draft and I support it and it's my opinion that it's useful and should proceed.
>

+1

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.

---

From: <[email-masked]>
Date: Thu, 14 Apr 2016 14:29:06 +0000

+1

> Am 06.04.2016 um 21:23 schrieb Vízdal Aleš <[email-masked]>:
> 
>

---

From: [email-masked]
Date: Fri, 15 Apr 2016 10:41:10 +0200

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

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

Cheers,
Ole

> On 22 Mar 2016, at 07:55, Yong Cui <[email-masked]> wrote:
> 
> Hi folks,
> 
> Yong Cui, Suresh Krishnan and Ian Farrer
> 
> 
>

---

From: Ian Farrer <[email-masked]>
Date: Tue, 19 Apr 2016 22:25:25 +0200

Hi Ole,

Thanks for the comments. Please see inline.

Cheers,
Ian

> On 15 Apr 2016, at 10:41, [email-masked] wrote:
> 

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