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

[Wojciech Dec <[e-mail]>]

Hi Suresh,


On 26 February 2014 02:10, Suresh Krishnan <[e-mail]>wrote:

> Hi Woj,
>
>
> On 02/25/2014 05:12 AM, Wojciech Dec wrote:
>
>> Hi Qi,
>>
>> your answers didn't answer the majority of the concerns raised. And some
>> of those raised by Ole still also stand:
>> - Clean-up text that does not belong to lw46 (eg 2473 fixes, NAT44 best
>> practice).
>> - Clarification of WAN selection or assumptions
>> - Clarify questionable use of ICMPv6 error code (to report lack of v4
>> binding)
>>
>> I still see no reason why they cannot be addressed by edits to the draft
>> that don't change the matter that lw46 is a standalone draft.
>>
>
> In all fairness, your comments came in a few hours before the draft
> submission deadline for this IETF. It is unreasonable to expect the issues
> to get addressed by draft changes, at least until the submission reopens. I
> do think the above points merit a response from the document editors.


Thanks.

>
>
> > - Text clarifying relation to MAP-E (both use MAP PSID algo, address
> > embedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to
> > be ranged from N to 1 per CPE. lw46 focuses on the 1:1 case)
>
> Why do you think this is required here? Isn't this the goal of the unified
> CPE work (to clarify the commonalities between MAP and lw4over6)?
>

There is a difference: Here I'm pointing out that IPinIP dataplane + ICMP
wise there should be no difference between lw46 and MAP-E, and in effect a
MAP BR or lw46 AFTR implementation of these would be no different. There is
no talk of provisioning.
uCPE attempts to bring in all mechanisms, also beyond -E and lw46, + their
various provisioning options for a single CPE.

Cheers,
Wojciech.

>
> Thanks
> Suresh
>
>
>>
>> Snipped text Inline... Woj>
>>
>>
>> On 21 February 2014 10:25, Qi Sun <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>     Hi Woj,
>>
>>
>>     On 2014-2-19, at 下午4:34, Wojciech Dec wrote:
>>
>>>
>>>     Just to be clear: I'm ok with lw46 defining a specific functional
>>>     mode as I believe it does in this draft,
>>>
>>
>>     [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but
>>     both use the Softwire DHCP for provisioning (at least according to
>>     my memory). That is why the WG decided to remove the statement of
>>     "lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft.
>>
>>     And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This
>>     is documented in the current lw4o6 draft, and some teams are doing
>>     the documentation work. (We have demoed in IETF85 that lw4o6 can
>>     work with DHCPv4 over IPv6 and PCP). The point is, lw4o6
>>     architecture is quite flexible.
>>
>>
>>
>> Woj>I didn't quite comment on the DHCP draft, nor on how flexible and
>> clear *you think* the lw46 draft is, etc. I commented on the fact that
>> that lw46 shares a lot with MAP-E and the fact that it is built on the
>> same technology blocks as MAP-E, but realizes solely the 1:1 part should
>> be clarified.
>>
>> Irrespective of this, there is overall no reason for having text in the
>> lw46 draft that fixes 2473 or NAT44 best practices, etc.
>>
>>
>>      also leaving "as-is" the DHCP part of it (i.e. it's a capability
>>>     that can be signalled using the lw46 container, etc).
>>>
>>
>>      General items remain open (as commented):
>>>     - Cleanup text that does not belong to lw46 (eg 2473 fixes, or
>>>     NAT44 best practice).
>>>
>>
>>     [Qi] IMO, that text guarantees the interoperation between lwAFTRs
>>     and lwB4s from different vendors, which bothered us a little when
>>     carrying out the interop test. I think it doesn't hurt to make it
>>     specific.
>>
>>
>> Woj>A couple of points:  Firstly: Given that the lwB4 CPE uses the MAP
>> algorithm for the PSID and embeds the IPv4+PSID in its IPv6 address, the
>> text is now in shape that a lwB4 would be interoperable with a MAP-E BR.
>> This is actually good convergence/progress. What remains open in that
>> happening is actually weeding out the possible source of differences,
>> which appear to be in the nuances of ICMP handling.
>>
>> Secondly: It claims to be a standards track document (currently), and it
>> carries text that selectively duplicates text in other standard rfcs
>> without deferring to those RFCs. If there are any reasons why this
>> "cherry picking" was made, while other recommendations (say re NAT44)
>> were not adopted, they should be clarified. In general for rfc2473,
>> there I see so far no zero reason to have some other text here, as
>> opposed to errata. Same for NAT44 really.
>>
>> Then again, perhaps the draft should be interpreted as an RFP of some
>> kind, which it actually reads a lot like. In which case it should not be
>> a standard track document.
>>
>>
>>      - Clarification of WAN selection or assumptions
>>>
>>
>>     [Qi] I think Ian has expressed cleared in previous mails.
>>
>>
>>
>> Woj>Please see my reply to Ian - looking forward to an answer in the
>> draft:
>> --snip--
>> So, in terms of the lw46 draft specifying how a CPE is to get to the IP
>> prefix of  "the WAN interface" is an important aspect, or at least
>> stating the assumptions about this WAN interface. Some obvious questions
>> apply here:
>> is the WAN the interface which has the default route? Is it the
>> interface that has a DHCPv6 client? What if there are multiple such
>> "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes?
>> What if it has NO global IPv6 prefix? What if it doesn't have a /64
>> prefix. etc.
>> --snip--
>> One doesn't see the draft answering any of these at the moment.
>>
>>
>>
>>>     That said, abundant technical evidence (summarized in previous
>>>     mail) indicates that this mode is in near total overlap with MAP
>>>     1:1, certainly much more than at the outset of this work. Given
>>>     this, why not align the text and actually make MAP 1:1 and lw46 be
>>>     the same? On all of the data plane IPv6, IPv4, NAT44, tunneling
>>>     and ICMP handling parts I see there no reason for there being a
>>>     difference...
>>>
>>
>>     [Qi] I think lw4o6 is clean and simple, and flexible to work with
>>     different provisioning mechanisms (signaling through the Softwire
>>     DHCP as is agreed by the WG).
>>
>>
>>
>>>     continued inline...
>>>
>>>
>>>
>>>
>>>         [ian] The draft already contains the following text (and has
>>>         for some time):
>>>
>>>             Lightweight 4over6 provides a solution for a hub-and-spoke
>>> softwire
>>>             architecture only.  It does not offer direct, meshed IPv4
>>>             connectivity between subscribers without packets traversing
>>> the AFTR.
>>>             If this type of meshed interconnectivity is required,
>>>             [I-D.ietf-softwire-map] provides a suitable solution.
>>>
>>>         So, are you not happy with the wording of the current
>>>         reference, or are you requesting that the draft is rewritten
>>>         to be cast as a ‘specialised' case of MAP?
>>>
>>>     What I pointed out is that the Lw46 draft has major if near total
>>>     overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode,
>>>     in a standalone way from the N:1 mesh mode, is what I propose.
>>>     This would greatly help in implementing it and "digesting" the
>>>     array of solutions.
>>>
>>
>>     [Qi] I don't see any "help" here...
>>
>>
>> Woj>To an operator and implementer, it would be very advantageous that
>> all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by
>> Softwire drafts are the same, unless it is made clear as to why they
>> should be different, and what does it bring. This applies especially to
>> lw46 and MAP, since there is so much overlap between the solutions.
>>
>>
>>      Additional comment Now that you mention it, the stated
>>>     characterisation of map isn't quite right; MAP does not force the
>>>     use of mesh mode, nor is mesh mode its defining characteristic.
>>>
>>
>>     [Qi] From my reading, the text doesn't characterize what MAP is. It
>>     just says "if you want to use meshed IPv4 connectivity, then use
>>     MAP". It doesn't prevent you from using MAP to do anything else. So
>>     I think the text is OK.
>>
>>
>> Woj> Well, that is "characterisation". From dictionary: "The act of
>> describing the character or qualities of someone or something"
>> And as stated, it is not quite correct, i.e. mesh-mode is not the
>> defining feature of MAP. The state optimization (stateless) is, of which
>> mesh mode is a by product (optional actually in the spec). The text
>> needs to be changed.
>>
>>
>>      The characterisation should be restated as " lw46 does not seek to
>>>     offer the optimization of AFTR subscriber state and the AFTR is
>>>     expected to have configuration state for each lwB4 node. If
>>>     optimization of this state is required, [id-ietf-softwire-map]
>>>     provides a suitable solution ".
>>>     Alternatively, state that "lw46 describes a
>>>     deployment/implementation of MAP 1:1"
>>>
>>>>
>>>>
>>>>
>>>>>             Detailed comments:
>>>>>
>>>>>             * Section 5.1 WAN prefix selection and address forming -
>>>>>             as per Ole's comment. This is indeed hand wavy in the
>>>>>             current draft (how to select the WAN?)
>>>>>
>>>>>             [ian] I’ve updated with the wording that I proposed to Ole.
>>>>>
>>>>>             The CPE WAN interface is a fairly well used term in a
>>>>>             number of other RFCs. Both RFC6333 and RFC7084 use the
>>>>>             term (and have implementations based on them) without
>>>>>             defining how the CPE has identified it. Why does that
>>>>>             need to be specifically defined here?
>>>>>
>>>>>
>>>>>         Woj>  What is the WAN interface is, and how should the CPE
>>>>>         "find it" not said. That other drafts fail to clarify that
>>>>>         doesn't make it quite right…
>>>>>
>>>>
>>>>
>>>>         [ian] No, this is related to fragmentation in respect to the
>>>>         RFC1858 'Tiny Fragment attack' which affects  the IPv4
>>>>         payload. The same problems exist for the lwB4s NAT44 function
>>>>         as exist for a NAT64 in this respect, which is why it was
>>>>         included.
>>>>
>>>>
>>>>     Woj> Ok, but what does "MAY require" mean, and how should a
>>>>     device go about requiring it?
>>>>
>>>
>>>      [Qi] Please see page 18 of RFC6146:
>>
>>            *  The NAT64 MAY require that the UDP, TCP, or ICMP header be
>>               completely contained within the fragment that contains
>>     fragment
>>               offset equal to zero.
>>
>>
>> Woj> Well, that text as you point comes from NAT64, and concerns IPv6
>> header chain to IPv4 header "fitting". In lwB4, unless I misunderstand,
>> the only fragmentation there may be is that of IPv4 that would be driven
>> by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the
>> draft is requiring here isn't clear.
>> In any case the fragmentation behaviour is not something specific to
>> lw46, so it would be best if you pointed the draft at the source.
>>
>>
>>
>>>>
>>>>             * Section 5.2: Text:
>>>>
>>>>             For incoming de-capsulated IPv4 packets carrying UDP
>>>> packets with a
>>>>
>>>>                 zero checksum, if the lwB4 has enough resources, the
>>>> lwB4 MUST
>>>>
>>>>                 reassemble the packets and MUST calculate the checksum.
>>>>  If the lwB4
>>>>
>>>>                 does not have enough resources, then it MUST silently
>>>> discard the
>>>>
>>>>                 packets.
>>>>
>>>>             Wouldn't it be easier to say that the lwb4 MAY reassemble
>>>>             the packet and recalculate the checksum? It's clearly not
>>>>             a MUST...
>>>>
>>>>             [ian] Why is it not a MUST? If one condition is met you
>>>>             MUST do this, if a different condition is met, you MUST
>>>>             do that. A MAY would make re-assembly of the packets
>>>>             optional, meaning that an implementation could not
>>>>             implement support for fragment reassembly at all and
>>>>             still say that it is compliant with the spec.
>>>>
>>>>
>>>>         If it were a MUST then something would horribly break if it
>>>>         were not done. The above clearly says that this reassembly
>>>>         operation is at the discretion of the device,  subject to an
>>>>         arbitrary "enough resources" condition. If you'd like it to
>>>>         be a MUST then the condition should be removed.
>>>>
>>>
>>>         [ian] Then surely re-assembly is a SHOULD requirement, with a
>>>         a MUST to discard if cannot be re-assembled. As I said, if it
>>>         was a MAY requirement, then implementation would be completely
>>>         optional.
>>>
>>>
>>>     Woj> Yes, and that's what the above text reads from a test
>>>     perspective, i.e. since one has no way of determining whether
>>>     there are "enough resources", a lwB4 that discards all such
>>>     packets would comply. As I said, if one would like to tighten the
>>>     spec; a) the un-testable "enough resources" condition should be
>>>     removed b) with that either a MUST used, if this is something
>>>     super important, or a SHOULD (as it seems to me). Alternatively a
>>>     MAY as "nice to have" may also do.
>>>
>>
>>     [Qi] I prefer to use a SHOULD for re-asembly and a MUST for
>>     discarding the packet if it cannot be reassembled.
>>
>>
>> Woj> Well, so it's a SHOULD then. Please note: the "enough resources"
>> condition as is, is un-testable across implementations, so adding such
>> "dead" text is rather pointless.
>>
>> Cheers,
>> Wojciech.
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>