Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

[<[e-mail]>]

Hi Ole,


Thanks for the review. Please see inline.

Cheers,
Ian

On 11/02/2014 11:28, "Ole Troan" <[e-mail]> wrote:

>a few initial comments:
>
>s/connectivity services/connectivity/
>s/OPTION_SW46_LW/OPTION_S46_CONT_LW/

[ian] OK

>
>section 5.1
>   An IPv6 address from an assigned prefix is also required for the lwB4
>   to use as the encapsulation source address for the softwire.  In
>   order to enable end-to-end provisioning, the IPv6 address is
>   constructed by taking a /64 prefix assigned to the WAN interface and
>   suffixing 64-bits for the interface identifier.  As there may be
>   multiple WAN prefixes, of which only one can be used for lw4o6, the
>   CPE is provisioned with the logic to select the correct one.  The /
>   128 prefix is then constructed as follows:
>
>that seems awfully hand-wavy?
>how is the CPE supposed to pick which prefix to use? does it have to be
>from the WAN interface?

[ian]Yes, it¹s built on the WAN interface. The intention is that the CPE
builds the tunnel from the prefix which it has just created. I guess it¹s
the following line that causes the hand waving:

As there may be multiple WAN prefixes, of which only one can be used for
lw4o6, the CPE is provisioned with the logic to select the correct one.

What about?:

As there may be multiple WAN prefixes, of which only one can be used for
lw4o6, the CPE creates a new WAN prefix specifically for use as the tunnel
source address.



>could it be from the PD block as well?

[ian] It could be from the PD block if it¹s using the PD_EXCLUDE¹d prefix,
but there¹s no requirement / necessity for the device with the lwB4
function to support PD to build a tunnel. The lwB4 function could be
implemented in an end host which wouldn¹t support PD.

>
>reference MAP for the interface-id? (or perhaps just state that it is the
>same)

[ian] I¹ll update to say that it¹s the same.

>define PSID somewhere? (reference MAP document)?

[ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic
port-restricted IPv4 address
        provisioning.  The port set algorithm for provisioning this is
        described in Section 5.1 of [I-D.ietf-softwire-map].

>
>why SHOULD the a-bits be 0? isn't that an operational choice?

[ian]Because there¹s no reason to use non-0 if you¹re not algorithmically
mapping, it just increases the complexity.

>
>I really don't think overriding the ICMP type 1 code 5 is appropriate to
>signal "no binding".

[ian] Do you think a different error ICMP error should be sent, or that
should be silently dropped?

>do you think the BR reachability check from RFC5969 could be adopted
>instead?

[ian] Possibly, although this would mandate that your lwAFTRs always had
traffic hair pinning enabled so the check could succeed.

This is a common softwire problem, though. From what I can see, if there
were inconsistencies in the MAP provisioning domain between CEs and BRs,
for any reason then it would fail with no errors being sent (although
there would be counters on the problem devices).

>
>should you say something about using anycast addresses for the AFTR?
>
>a general comment. we're going to have quite a bit of redundant text
>between the MAP documents and the LW46 document, e.g. ICMP handling,
>fragmentation. I don't have a big problem with that as such, but should
>ensure that the text isn't conflicting at least.

[ian] Some redundancy is inevitable. I _hope_ that by now we¹ve ironed out
any conflicts - I¹m certainly not aware of any.

>
>cheers,
>Ole
>
>On 11 Feb 2014, at 8:54 , [e-mail] wrote:
>
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Softwires Working Group of the IETF.
>> 
>>        Title           : Lightweight 4over6: An Extension to the
>>DS-Lite Architecture
>>        Authors         : Yong Cui
>>                          Qiong Sun
>>                          Mohamed Boucadair
>>                          Tina Tsou
>>                          Yiu L. Lee
>>                          Ian Farrer
>> 	Filename        : draft-ietf-softwire-lw4over6-06.txt
>> 	Pages           : 22
>> 	Date            : 2014-02-10
>> 
>> Abstract:
>>   Dual-Stack Lite (RFC 6333) describes an architecture for transporting
>>   IPv4 packets over an IPv6 network.  This document specifies an
>>   extension to DS-Lite called Lightweight 4over6 which moves the
>>   Network Address and Port Translation (NAPT) function from the
>>   centralized DS-Lite tunnel concentrator to the tunnel client located
>>   in the Customer Premises Equipment (CPE).  This removes the
>>   requirement for a Carrier Grade NAT function in the tunnel
>>   concentrator and reduces the amount of centralized state that must be
>>   held to a per-subscriber level.  In order to delegate the NAPT
>>   function and make IPv4 Address sharing possible, port-restricted IPv4
>>   addresses are allocated to the CPEs.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-06
>> 
>> 
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>