Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 17 Jul 2020 19:19:40 +0000

Hi Jordi,
How Carrier would know that user has brought additional device (TV for example) to his residence?
Or let’s ask in simpler form: how Carrier would know how many StupidTVs (IPv4 only) user already have?
What to program in centralized IT system?
IMHO: the whole Approach #3 (clause 5.3) does not make sense.
Would you agree to delete it?
As you mentioned in the draft: It is useless anyway without protocol to upload EAMT.
Eduard

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Jul 2020 23:54:46 +0200

Hi Eduard,

Responding to this one as it is “short”,  I will continue with the others tomorrow and across the weekend.

The operator doesn’t need to know which customers have “old” TVs. The operator can either push the EAMT or have it in some server so the CEs can pull it.  We can rely on many existing protocols for that, or even provide it as part of the document itself, but that only makes sense if other issues are resolved.

The main difficulty for this approach is that CDNs are used to do frequent changes at the DNS level, so unless the CDNs are offering an API or something-like to update the EAMT of the operator, it will become more complex. The operator could just cache the most frequent FQDNs being resolved in their own DNS and based on the TTLs, update the table and push it to the CEs, etc. There are many possible solutions.

The document exposes different possible solutions. We have considered 3, in other RFCs  there are even more.  For example I was reviewing draft-ietf-v6ops-nd-cache-init a few days ago, and it presents about 8 solutions and suggest one as the most reasonable.

So in my opinion is perfeclty valid to have several choices and then decide. Note that when we started  the document it was not clear  for us,  the document keeps growing, and we may change our minds about what solution is better, depending on the inputs, however, I think it is important to keep all  the possible solutions documented even if it is clear that they don’t make sense.

Regards,

Jordi

@jordipalet

El 17/7/20 21:19, "Vasilenko Eduard" <[email-masked]> escribió:

Hi Jordi,

Eduard

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Vasilenko Eduard <[email-masked]>
Date: Sat, 18 Jul 2020 07:20:39 +0000

Hi Jordi,
May be then to copy some information from this answer to 5.3.
Because it looks now like “mission impossible”.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: 18 июля 2020 г. 0:55
To: V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration

Hi Eduard,

Regards,
Jordi
@jordipalet

El 17/7/20 21:19, "Vasilenko Eduard" <[email-masked]<mailto:[email-masked]>> escribió:

Hi Jordi,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Jul 2020 05:53:17 -0300

On 18/7/20 04:20, Vasilenko Eduard wrote:
[....]
> So in my opinion is perfeclty valid to have several choices and then 
> decide. Note that when we started  the document it was not clear  for 
> us,  the document keeps growing, and we may change our minds about what 
> solution is better, depending on the inputs, however, I think it is 
> important to keep all  the possible solutions documented even if it is 
> clear that they don’t make sense.

If something does not really make sense, I don't really see that point 
of "documenting" it -- unless it's an existing practice that one is 
planning to recommend against.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Jul 2020 12:45:24 +0200

Yep, good point making it more explicit.

Regards,

Jordi

@jordipalet

El 18/7/20 9:21, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

Hi Jordi,

Eduard

Hi Eduard,

Regards,

Jordi

@jordipalet

Hi Jordi,

Eduard

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

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2020 20:07:37 +1000

> The document exposes different possible solutions. We have considered 3, in other RFCs  there are even more.  For example I was reviewing draft-ietf-v6ops-nd-cache-init a few days ago, and it prese…

;) Let me comment on it ;)
The reason nd-cache-init lists all those options is some of them *are*
implemented and could be seen in the wild. So the draft tries to
explain why GRAND is proposed. We are not saying 'don't do this ever',
we are saying 'we believe that would work (and does work) but there
are limitations, so let's do GRAND'.
I'm afraid option 3 in this draft is slightly different. Do we know
any actual implementations?

> So in my opinion is perfeclty valid to have several choices and then decide. Note that when we started  the document it was not clear  for us,  the document keeps growing, and we may change our min…

The only concern here is that there are an endless number of solutions
which do not make sense ;)
I can suggest one more:
- The main driver of the document and the underlying problem we are
solving seems to be the cost of deploying NAT64 at large scale. If
operators can do the second translation for free, we wouldn't even
have this draft, right? So operators could start charging users based
on IPv6/IPv4 traffic ratio ;) Remember all those cases when your
uplink charged you based on egress/ingress ratio? '5% discount if your
monthly IPv6/IPv4 ration is above 70%'
As a result, users would suddenly start caring about that weird IPv6
thingy and maybe even ask for IPv6-enabled TVs. Operators get some of
their CapEx shifted to users ;)

On a serious note: maybe you can separate the proposed option from
discarded ones more clearly - like different sections or even
Appendix?

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

-- 
SY, Jen Linkova aka Furry