Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 26 February 2014 01:10 UTC
Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98A1A081D for <softwires@ietfa.amsl.com>; Tue, 25 Feb 2014 17:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.599
X-Spam-Level: **
X-Spam-Status: No, score=2.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTVEAM0GKn79 for <softwires@ietfa.amsl.com>; Tue, 25 Feb 2014 17:10:25 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6591A0283 for <softwires@ietf.org>; Tue, 25 Feb 2014 17:10:25 -0800 (PST)
X-AuditID: c6180641-b7f2f8e000002cdc-9c-530d3f007317
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5B.D2.11484.00F3D035; Wed, 26 Feb 2014 02:10:24 +0100 (CET)
Received: from [164.48.125.55] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 25 Feb 2014 20:10:22 -0500
Message-ID: <530D3EEC.8040201@ericsson.com>
Date: Tue, 25 Feb 2014 20:10:04 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Wojciech Dec <wdec.ietf@gmail.com>, Qi Sun <sunqi.csnet.thu@gmail.com>
References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <FD878467-904B-4441-95B4-11D4461A612E@employees.org> <CF237FDE.AACEB%ian.farrer@telekom.de> <CAFFjW4jOBfvnqCV4UH8qt0HA5zZ-35f+q5ZepzjnwGX5_Oj9Gg@mail.gmail.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <CAFFjW4iP2KqNJFtJPr5rp0tzRwM5TPjaqiSP5r13JqbX46ao7w@mail.gmail.com> <CD1D4FF6-9509-43B4-AFC4-4F1AF99D0C4D@gmx.com> <CAFFjW4ibkj_xpTuXrbYjxkdxD=+qNzapCGPHJwXsZ-k0ZvGg-g@mail.gmail.com> <EBAECD54-9E78-4B07-BC8F-032B585AE0EE@gmail.com> <CAFFjW4hEBF3ZTnGXv+0ncTb981Mr_mdMW04EW=ZqBWFSRE9Q-Q@mail.gmail.com>
In-Reply-To: <CAFFjW4hEBF3ZTnGXv+0ncTb981Mr_mdMW04EW=ZqBWFSRE9Q-Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [147.117.188.8]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyuXRPrC6DPW+wwc77OhaHl21lsuibfJvR omXhLWYHZo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PtsalMBcczKrY8mc7YwLjbt4uR k0NCwETi7u6rbBC2mMSFe+uBbC4OIYEjjBJ7ml5AOVsZJR7dPwvkcHDwCmhLLJvvA9LAIqAq saT3AiuIzQY0aMPOz0wgtqhAmET7hZnMIDavgKDEyZlPWEBsEQEviYkPZoMtYwbqXfr/CiOI LSzgIfFvxyEWiF0PWCQuz3gOVsQpEChxffVxZogGC4nFbw6yQ9jyEs1bZ4PFhQQ0Jbau+c4K 8YGixIvjP5kmMArNQrJ7FpL2WUjaFzAyr2LkKC1OLctNNzLcxAgM3GMSbI47GBd8sjzEKM3B oiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxjRDueW2FoHO+/YIHJGcbHAvU+Tn SQU+1rIfamXHua6feD117Yfjzxena/Bplc78/Fg/ZuZjE6NdOzaIa3W85qkI17rl/yH1y6Gi ySGlZ2UOGSdVVc9savu0yPb1vcf+i0Qk1RbECr1PTNggG7Vq9ZrgNYfEr5ro7Cw6sZg7REPW /couht4UdiWW4oxEQy3mouJEABkCISEqAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/AUhZKrKrXkeYuk-83T6ytJQm9xE
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 01:10:28 -0000
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. > - 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)? Thanks Suresh > > > Snipped text Inline... Woj> > > > On 21 February 2014 10:25, Qi Sun <sunqi.csnet.thu@gmail.com > <mailto:sunqi.csnet.thu@gmail.com>> 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 > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >
- [Softwires] I-D Action: draft-ietf-softwire-lw4ov… internet-drafts
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… ian.farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… ian.farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Qi Sun
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Tom Taylor
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Suresh Krishnan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… ian.farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Lee, Yiu
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Satoru Matsushima
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Satoru Matsushima
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Qi Sun
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Satoru Matsushima
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Simon Perreault
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Lee, Yiu
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Axel.Clauberg
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Senthil Sivakumar (ssenthil)
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Simon Perreault
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Simon Perreault
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Suresh Krishnan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Tom Taylor
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Simon Perreault
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Lee, Yiu
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Qi Sun
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Yuchi Chen
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Tina TSOU
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Tom Taylor
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Lee, Yiu
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Lee, Yiu
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Qi Sun
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Cong Liu
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Qiong
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Yuchi Chen
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ian Farrer
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Yuchi Chen
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Lee, Yiu
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Tom Taylor
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Qiong
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Wojciech Dec
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… Tom Taylor
- Re: [Softwires] I-D Action: draft-ietf-softwire-l… ian Farrer