Hi Suresh,
On 26 February 2014 02:10, Suresh Krishnan <[email protected]>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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> >> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
