Subject: [Softwires] Fwd: Re: I-D Action: draft-ietf-softwire-lightweight-4over6-deployment-01.txt

From: Yannis Nikolopoulos <[email-masked]>
Date: Wed, 9 Aug 2017 17:32:31 +0300

forwarding this to the list also, in case anyone cares to comment

regards,
Yannis

-------- Forwarded Message --------
Subject: 	Re: [Softwires] I-D Action: 
draft-ietf-softwire-lightweight-4over6-deployment-01.txt
Date: 	Sat, 8 Jul 2017 23:13:29 +0300
From: 	Yannis Nikolopoulos <[email-masked]>
To: 	[email-masked], [email-masked], [email-masked], 
tianxiang li <[email-masked]>, Farrer, Ian (DTAG) 
<[email-masked]>
CC: 	Nikolopoulos Yannis <[email-masked]>

Dear authors ,

as I said in the past, I believe that this is a very useful draft. We,
at OTE Greece are also deploying LW4o6 so if
you need to enrich the draft's test cases let me know.

Also, please find a few comments below:

"1. intro

  The logging requirements to meet regulatory requirements may be
       reduced as it is only necessary to log when a subscriber is
       provisioned or de-provisioned in the lwAFTR.  This relaxes the
       need for logging on a per-session, or per port block allocation."

[YN]: One still cannot comply with regulatory requirements because of
the A+P model (and because most servers on the internet do not log the
client's port number).So, how are the regulatory requirements reduced?

"3.1.  IP Addressing and Routing

    In Lightweight 4over6, there is no inter-dependency between the IPv4
    and IPv6 addressing schemes.  This allows for complete flexibilty in
    addressing architecture."

[YN]: although true, the above statement can be a bit misleading. I
believe that it should be mentioned that a proper addressing scheme for
IPv6 (lw4o6 esp.) should already be in place and ideally, IPv4 ranges
should be predefined (for routing efficienncy, e.g contiguous ranges)

"3.1.1.  IPv4 Routing

    The IPv4 addresses/prefixes that are allocated to customer's lwB4s
    are advertised to the IPv4 Internet as being reachable via the
    lwAFTR(s).  If multiple lwAFTRs are all serving the same set of
    lwB4s, all will advertise the same IPv4 reachable routes."

YN: if multiple lwAFTRs, IPv4 prefixes could also be split, for routing
efficiency. That all depends on operator's and operator's upstream
topology and PoPs

best regards,

Yannis

On 07/03/2017 06:58 PM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Softwires of the IETF.
>
>          Title           : Deployment Considerations for Lightweight 4over6
>          Authors         : Qiong Sun
>                            Chongfeng Xie
>                            Yiu L. Lee
>                            Maoke Chen
>                            Tianxiang Li
>                            Ian Farrer
> 	Filename        : draft-ietf-softwire-lightweight-4over6-deployment-01.txt
> 	Pages           : 23
> 	Date            : 2017-07-03
>
> Abstract:
>     Lightweight 4over6 is a mechanism for providing IPv4 services to
>     clients connected to a single-stack IPv6 network.  The architecture
>     is similar to DS-Lite, but the network address translation function
>     is relocated from the tunnel concentrator to the tunnel client, hence
>     reducing the amount of state which must be maintained in the
>     concentrator to a per-customer level.  This document discusses the
>     applicability, describes various deployment models and provides
>     deployment considerations for Lightweight 4over6.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-lightweight-4over6-deployment/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-lightweight-4over6-deployment-01
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-lightweight-4over6-deployment-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lightweight-4over6-deployment-01
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Thu, 10 Aug 2017 12:32:53 +0000

Hi Yannis,

Please see inline.

Cheers,
Med

De : Softwires [mailto:[email-masked]] De la part de Yannis Nikolopoulos
Envoyé : mercredi 9 août 2017 16:33
À : Softwires WG
Objet : [Softwires] Fwd: Re: I-D Action: draft-ietf-softwire-lightweight-4over6-deployment-01.txt

-------- Forwarded Message --------
Subject:

Re: [Softwires] I-D Action: draft-ietf-softwire-lightweight-4over6-deployment-01.txt

Date:

Sat, 8 Jul 2017 23:13:29 +0300

From:

Yannis Nikolopoulos <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, tianxiang li <[email-masked]><mailto:[email-masked]>, Farrer, Ian (DTAG) <[email-masked]><mailto:[email-masked]>

CC:

Nikolopoulos Yannis <[email-masked]><mailto:[email-masked]>

Dear authors ,

"1. intro

[Med] You are right. That text you quoted should explicitly mention that it assume that source port logging is used or that authorities in a given country are OK with reveal all the subscribers that are sharing a given address. This may be acceptable if a low address sharing ratio is used.

BTW, these considerations are not unique to A+P, but are the same for DS-Lite when port ranges are in used. In a DS-Lite context, logging the destination address + timestamping may be adequate, but there are trade-offs there: see https://tools.ietf.org/html/rfc6908#section-2.3

This following text should be updated:

OLD:

   This can bring a number of advantages when compared to DS-Lite:

   o  Per-subscriber configuration allows for the operator to provision
      each subscriber according to their specific service requirements.

  o  The logging requirements to meet regulatory requirements may be
      reduced as it is only necessary to log when a subscriber is
      provisioned or de-provisioned in the lwAFTR.  This relaxes the
      need for logging on a per-session, or per port block allocation.

   o  In some lw4o6 deployment topologies, the removal of per-session
      state means that it is possible to have very large parallelisation
      of lwAFTR elements.  This offers excellent scaling and resilience.

   o  This mechanism preserves the dynamic feature of IPv4/IPv6 address
      binding as in DS-Lite, so it has no coupling between IPv6 address
      and IPv4 address/port-set as any full stateless solution
      ([RFC6052<https://tools.ietf.org/html/rfc6052>] or [RFC7597<https://tools.ietf.org/html/rfc7597>]) requires.

NEW:

   This can bring a number of advantages when compared to DS-Lite:

   o  In some lw4o6 deployment topologies, the removal of per-session
      state means that it is possible to have very large parallelisation
      of lwAFTR elements.  This offers excellent scaling and resilience.

All other items are also valid for DS-Lite.

[Med] I do think the text you quoted is accurate. There is no inter-dependency between IPv6 addressing and IPv4 one.

"3.1.1.  IPv4 Routing

topology and PoPs

[Med] Agree.

best regards,

Yannis

> [email-masked]<mailto:[email-masked]>