Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Mar 2019 21:49:18 +0100

Hi Alejandro,

Responding below, in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alejandro D'Egidio <adegidio=[email-masked]>
Fecha: miércoles, 6 de marzo de 2019, 20:58
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

    Hello Jordi,
    Thanks for helping with this scenario of CDNs, please let's work together on it.
    As a summary you consider these scenarios always in a IPv6-only access network (which is the case):
    1- IPv6 capable device/app: it can directly connects to IPv6 service (CDN, etc).
    2- IPv4 only device/app: they need to use a PLAT to access to the service.
    
    I think we can include, as a part of introduction, the actual case of why ISPs need to continue providing IPv4 to have a direct connection to CDNs avoiding CGN, something like:
                                                   .--+--.	
                                                  /       \
                                                 /  IPv4   \
                                                (  Internet )
                                                /\         /
                                               /  \       /\
                                              /    `-----'  \
                      +-------+     .-----.  /               \  .-----.
                      | IPv6  |    /       \/                 \/ Dual- \
          .-----.     |  CE   |   /         \     .-----.     /  Stack  \
         / IPv4- \    |  or   +--(   DS      )---(  CGN  )---(           )
        /  only   \   |  UE   |   \  Access /\    `-----'     \  CDNs/  /
       (  SmartTV  )--+       |    \       /  \                \ Caches/
        \   STB   /   | with  |     `-----'    \   .-----.    / `--+--'
         \ VoIP  /    |       |                 \ /       \  /
          `-----'     | CLAT  |                  /  IPv6   \/ 
                      |   +   |                 (  Internet )
                      | IPv4- |                  \         /
                      |  CGN  |                   \       /  
                      +-------+                    `-----'   
    
    Showing that private IPv4 (typically 100.64.0.0/10) can connect directly to CDNs with public IPv4.

-> I can't see the picture very well, but I guess you mean to include the example of what the CDNs do for avoiding the 100.64.0.0/10 traffic via the CGN. I'm wondering if this is the same for CDNs and caches ... We should have a clear picture if all them are doing it the same way and describe it. Probably it may be better to have it in a different section, something like "Comparative situation in IPv4 CGN traffic".

    After the text:
    "As show in the precedent picture, this is also the case for other
       services, not just CDNs or caches, such as VoIP access to the
       relevant operator infrastructure, which may be also dual-stack, but
       is not commonly the case for many VoIP devices or applications."
    
    Can be included a note saying that this is the scenario where ISPs and CDNs need to have a direct connection without CGN avoiding the sizing and translation impact of CGN.
    
    About the approachings:
    DNS/Routing-based Solution Approach: I think that is a good idea. The thing here is to know how possible is this to be considered by CNDs. Also, this scenario is just possible if CPE is in router mode.

-> I heard from CDNs that this approach is not so easy. The way they handle the DNS make it difficult. For caches may be.
    
    CLAT/DNS-proxy-EAMT-based Solution Approach: I think this is a better approach where is not necessary to modify anything in CDNs.
    I see two things:
    a. How long is the timeout of the EAMT entry?
-> Time out should probably be consistent with the TTL of A records (I've sent another email about this, because I didn't include it in v00)

    b. How to determine which FQDNs CLAT needs to verify if there is an AAAA record? If it tries with all A records it can have a service impact (more delay thinking about a lot of queries per second).
-> I think is easy. A dual-stack will query for the A and AAAA records. If the DNS-proxy is only queried for the A record, it must also query for the AAAA and build the EAMT entry. I don't this is heavy at all for the CPE DNS proxy. 

    CLAT-provider-EAMT-based Solution Approach: Really hard to implement and to maintain. It depends on features of provisioning systems. With CM we can think on:
    Push this information to millions of devices using SNMP and pray to all CMs are online what is not true because there are always CMs offline.
    Include this information into a config-file and restart all CMs!?
    
    For both cases how to update some change to all CMs?

    I think the best approach is CLAT/DNS-proxy but I'm worried about A record queries delay where destination is an external service.

-> Yes, agree, I think approach number 2 (CLAT responsible for building the EAMT) may be the best choice. Regarding the delay, think on it this way. If it was a host with dual-stack, the query will be done anyway for both the A and AAAA records, not a big impact.

    Regards,
    ALEJANDRO D'EGIDIO 
    Jefe de Ingeniería de Backbone | Dirección de Ingeniería 
    M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 11 3977-1025 | +54 11 3977-1025 ] | [ mailto:[email-masked] | [email-masked] ] 
    Pje. Lavardén 157. Piso 3. CABA (C1437FBC)
    
    ----- Mensaje original -----
    De: "JORDI PALET MARTINEZ" <jordi.palet=[email-masked]>
    Para: "[email-masked] list" <[email-masked]>
    Enviados: Miércoles, 6 de Marzo 2019 6:53:56
    Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
    
    One important consideration that I missed in the submitted version.
    
    In the case of the "operator provided EAMT" (section 5), there is no need to have a "match" with the AAAA records. So, we can have for example:
    www.example.com                   A       192.0.2.1
                                      AAAA    2001:db8::192.0.2.2
    EAMT pushed entry              192.0.2.1  2001:db8::192.0.2.33
    CLAT translated to                        2001:db8::192.0.2.33
    CDN IPv6 interface already is             2001:db8::192.0.2.33
    Operator already has a specific route to  2001:db8::192.0.2.33
    
    The problem of this alternative is now to "renew" the EAMT info, with will depend on the mechanism to tell the CE (or the CE to ask if we go for a pull instead of a push) ...
    
    One more issue, how much time the EAMT information is kept in the case of the "automated" EAMT (section 4). May be with every A record request this entry should be cleared and otherwise use the default TTL from the A record?. This seems to avoid having a mechanism to configure the table at the CE.
    
    I think the information that the CDN operators can provide will be key to determine which approach is better, or may be to figure out new approaches.
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de Jordi Palet Martínez <jordi.palet=[email-masked]>
    Fecha: miércoles, 6 de marzo de 2019, 10:22
    Para: "[email-masked] list" <[email-masked]>
    Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
    
        Hi all,
        
        I've submitted this document after the questions from Alejandro for CDN optimization with IPv4aaS.
        
        https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/
        
        I think, in addition to operators, it will be interesting to have the views of CDN/cache operators, not sure if we have people related to this in the list, such as Akamai, Netflix, AWS, Facebook, Google, etc.
        
        We know that today some of them already do this optimization to avoid the CGN when using the 100.64.0.0/10 prefix.
        
        Regards,
        Jordi

        -----Mensaje original-----
        De: <[email-masked]>
        Fecha: miércoles, 6 de marzo de 2019, 10:10
        Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
        Asunto: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

            A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
            has been successfully submitted by Jordi Palet Martinez and posted to the
            IETF repository.
            
            Name:		draft-palet-v6ops-464xlat-opt-cdn-caches
            Revision:	00
            Title:		464XLAT Optimization for CDNs/Caches
            Document date:	2019-03-06
            Group:		Individual Submission
            Pages:		9
            URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
            Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/
            Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-caches-00
            Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464xlat-opt-cdn-caches

            Abstract:
               This document describes the drawbacks of IP/ICMP Translation
               Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
               applications initiate traffic flows to dual-stack CDNs (Content
               Delivery Networks) or Caches, which are forced to be translated back
               to IPv4 by a NAT64.  The document proposes possible solutions to
               avoid that.

            
            Please note that it may take a couple of minutes from the time of submission
            until the htmlized version and diff are available at tools.ietf.org.
            
            The IETF Secretariat

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

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

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

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

**********************************************
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: Alejandro D'Egidio <[email-masked]>
Date: Thu, 7 Mar 2019 09:25:03 -0300 (ART)

Hello Jordi,
My answers in line also.

Regards,
Alejandro

----- Mensaje original -----
> Enviados: Miércoles, 6 de Marzo 2019 17:49:18

> De: v6ops <[email-masked]> en nombre de Alejandro D'Egidio
> <adegidio=[email-masked]>
> Asunto: Re: [v6ops] New Version Notification for
> draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt
> 
>    Hello Jordi,
>    I think we can include, as a part of introduction, the actual case of why ISPs
>    need to continue providing IPv4 to have a direct connection to CDNs avoiding
>    CGN, something like:
>                                                   .--+--.
>                                                  /       \
>                                                 /  IPv4   \
>                                                (  Internet )
>                                                /\         /
>                                               /  \       /\
>                                              /    `-----'  \
> -> I can't see the picture very well, but I guess you mean to include the
> example of what the CDNs do for avoiding the 100.64.0.0/10 traffic via the CGN.
> I'm wondering if this is the same for CDNs and caches ... We should have a
> clear picture if all them are doing it the same way and describe it. Probably
> it may be better to have it in a different section, something like "Comparative
> situation in IPv4 CGN traffic".
Strange you can't see the picture. I attach it. The idea is to show the actual case of why ISPs with CGN and CDNs need to have a direct connection with IPv4 without using a CGN.
If there is no new definition (this draft) ISPs and CDNs will continue using IPv4 in access network.
I think is better to include a simple part in introduction because regarding that we are thinking about this new draft.
Then, we can have a section with additional information of how it's implemented although it's not necessary because it's not the point of the document, that's why the idea of just introduction.

>    Can be included a note saying that this is the scenario where ISPs and CDNs need
>    to have a direct connection without CGN avoiding the sizing and translation
>    impact of CGN.
>    
>    About the approachings:
>    DNS/Routing-based Solution Approach: I think that is a good idea. The thing here
>    is to know how possible is this to be considered by CNDs. Also, this scenario
>    is just possible if CPE is in router mode.
> 
> -> I heard from CDNs that this approach is not so easy. The way they handle the
> DNS make it difficult. For caches may be.
Yes, I agree.

>    
>    CLAT/DNS-proxy-EAMT-based Solution Approach: I think this is a better approach
>    where is not necessary to modify anything in CDNs.
>    I see two things:
> -> Time out should probably be consistent with the TTL of A records (I've sent
> another email about this, because I didn't include it in v00)
Yes, I suppose.

> 
>    b. How to determine which FQDNs CLAT needs to verify if there is an AAAA record?
>    If it tries with all A records it can have a service impact (more delay
>    thinking about a lot of queries per second).
> -> I think is easy. A dual-stack will query for the A and AAAA records. If the
> DNS-proxy is only queried for the A record, it must also query for the AAAA and
> build the EAMT entry. I don't this is heavy at all for the CPE DNS proxy.
Yes, maybe it wont have a big impact but by default it will try to find the AAAA record for all A records queries from hosts.
An additional case related to this is when a customer has an additional router behind the provided CPE. If this additional router doesn't support these new features, I think EAMT entries can solve it.

> 
>    CLAT-provider-EAMT-based Solution Approach: Really hard to implement and to
>    maintain. It depends on features of provisioning systems. With CM we can think
>    on:
>    Push this information to millions of devices using SNMP and pray to all CMs are
>    online what is not true because there are always CMs offline.
>    I think the best approach is CLAT/DNS-proxy but I'm worried about A record
>    queries delay where destination is an external service.
>    
> 
> -> Yes, agree, I think approach number 2 (CLAT responsible for building the
> EAMT) may be the best choice. Regarding the delay, think on it this way. If it
> was a host with dual-stack, the query will be done anyway for both the A and
> AAAA records, not a big impact.
I agree but the idea is to think about devices and apps that only support IPv4.

>    M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 11
>    3977-1025 | +54 11 3977-1025 ] | [ mailto:[email-masked] |
>    [email-masked] ]

---

From: Alejandro D'Egidio <[email-masked]>
Date: Mon, 11 Mar 2019 09:07:58 -0300 (ART)

Hello Jordi,
  Have you seen the last email?
  Have you been able to upload a new version?

Regards,
Alejandro

----- Mensaje original -----
De: "Alejandro Degidio" <[email-masked]>
Para: "JORDI PALET MARTINEZ" <jordi.palet=[email-masked]>
CC: "[email-masked] list" <[email-masked]>
Enviados: Jueves, 7 de Marzo 2019 9:25:03
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

Hello Jordi,
My answers in line also.

Regards,
Alejandro

----- Mensaje original -----

Yes, I agree.

Yes, I suppose.