[Softwires] Publication has been requested for draft-ietf-softwire-map-radius-22

Ian Farrer has requested publication of draft-ietf-softwire-map-radius-22 as None on behalf of the SOFTWIRE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ ___ Softwires mailing

[Softwires] Publication has been requested for draft-ietf-softwire-yang-06

Ian Farrer has requested publication of draft-ietf-softwire-yang-06 as None on behalf of the SOFTWIRE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ ___ Softwires mailing list Softwires

[Softwires] Publication has been requested for draft-ietf-softwire-mesh-multicast-22

Ian Farrer has requested publication of draft-ietf-softwire-mesh-multicast-22 as Proposed Standard on behalf of the SOFTWIRE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast

Re: [Softwires] RFC7597/9 MAP and iptables/netfilter

Hi Richard, Please see inline. Thanks, Ian > On 15 Feb 2018, at 15:47, Richard Patterson wrote: > > Hi All, > > Apologies, I was unsure on if this belonged in v6ops, softwires or > elsewhere, but I'll start here. > > I've been putting MAP-T through its paces in our lab

Re: [Softwires] Work Group Last Call for draft-ietf-softwire-mesh-multicast-19 - Ends Jan 25th

s/ when traversing AFBR./ when traversing an AFBR./ --- Para 2. s/in IPv4 and IPv6 address family./in the IPv4 and IPv6 address families./ --- Para 3. "In Figure 8, the semantics of fields "PIM Ver", "Type", "Reserved", and "Checksum" remain the s

Re: [Softwires] Review of draft-ietf-softwire-yang-03

Hi Linhui, Could you provide a proposed structure for your suggestion of using only ‘if-feature’? Thanks, Ian > On 12. Jan 2018, at 13:14, Linhui Sun <lh.sunl...@gmail.com> wrote: > > > 2018-01-12 20:04 GMT+08:00 Ian Farrer <ianfar...@gmx.com > <mailto:ianfa

Re: [Softwires] Review of draft-ietf-softwire-yang-03

Hi Linhui, > > 4) The usage of choice statement is not very clear, why do we need to use > > the 'case' and 'feature' statements together? It seems that we only need > > one of them. > > [if - Well, a CE may implement binding and/or algorithm. If it implements > one, then there is no choice

Re: [Softwires] Review of draft-ietf-softwire-yang-03

Hi Linhui, I agree with your comments on 1,3 and 5. Comments on 2&4 below. Thanks, Ian > > 2) The BR module should also augments ietf-interfaces since they are also a > tunnel endpoint and it is better to be consistent with the CE model. And in > this way, we do not need to declare the

[Softwires] Work Group Last Call for draft-ietf-softwire-mesh-multicast-19 - Ends Jan 25th

Hi, The authors believe that draft-ietf-softwire-mesh-multicast-19 is now ready for advancement. This email marks the start of a 2 week work group last call for the draft. Please send your comments, either for or against, to the softwire WG mailing list. The WGLC will end on Jan. 25, 2018.

[Softwires] Publication has been requested for draft-ietf-softwire-dslite-yang-14

Ian Farrer has requested publication of draft-ietf-softwire-dslite-yang-14 as Proposed Standard on behalf of the SOFTWIRE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang

[Softwires] draft-ietf-softwire-yang-03 posted

Hi, We’ve just submitted v03 of this draft. Changes from -02 are: * Incorporated comments received on the mailing list * Use of the term ‘module’ instead of ‘model’ throughout * Removal of old revision fields * br-ipv6-addr in the CE module now mandatory * Updated security section to include

Re: [Softwires] Tags changed for draft-ietf-softwire-dslite-yang

Hi Med, > [if - It was only cited as an informative reference in 07, so there shouldn’t > be a dependency problem] > [Med] The point is that I’m questioning that citation as an informative > reference. Because a reader must look at that document to understand the > meaning of the symbols, it

Re: [Softwires] Tags changed for draft-ietf-softwire-dslite-yang

Hi Med, Please see inline. Cheers, Ian > On 13. Nov 2017, at 18:28, <mohamed.boucad...@orange.com> > <mohamed.boucad...@orange.com> wrote: > > Re-, > > Please see inline. > > Cheers, > Med > > De : Ian Farrer [mailto:ianfar...@gmx.com <

Re: [Softwires] Tags changed for draft-ietf-softwire-dslite-yang

Hi Med, Thanks for the update. I’ve just checked through this version. For some reason, section 1.2 has reverted to an earlier version with explicit instructions for the tree diagram (this wasn’t the case in 07). This was from Mahesh’s YANG doctor review, and your response from 9th October:

Re: [Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

ge.com> > <mohamed.boucad...@orange.com> wrote: > > Re-, > > OK. The updated version with your comments will be submitted next Monday. > > Cheers, > Med > > De : Ian Farrer [mailto:ianfar...@gmx.com] > Envoyé : vendredi 10 novembre 2017 12:43 > À : BOUCADAI

Re: [Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

Hi Med, >> >> Model comments: >> m1. v6-v4-dscp-preservation - deals with whether the DCSP of the incoming >> packet will be copied to the header of the outgoing packet or not. >> Would this be better implemented as a feature in the model, as this would >> allow the use in the mapping entry to

Re: [Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

with the following sentence ' This information can be used by the AFTR fro enforcing the poi’. Unsure what this is meant to say. Section 7 g4. s/eraly ynagdoctors/early yangdoctors/ g5. s/comments/comments./ > On 26. Oct 2017, at 09:09, Ian Farrer <ianfar...@gmx.com> wrote: > > Hi, > >

Re: [Softwires] I-D Action: draft-ietf-softwire-yang-02.txt

-in-IPv6 Address plus >> Port Softwires >>Authors : Qi Sun >> Hao Wang >> Yong Cui >> Ian Farrer >> Sladjana Zechlin >>

[Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov

Hi, The authors believe that draft-ietf-softwire-dslite-yang-07 is now ready for advancement. This email marks the start of a 2 week work group last call for the draft. Please send your comments, either for or against, to the softwire WG mailing list. The WGLC will end on Nov. 9, 2017.

Re: [Softwires] WGLC for draft-ietf-softwire-map-mib-10

Hi Yu, Please see below. Thanks, Ian > On 25. Oct 2017, at 11:28, Yu Fu wrote: > > >g3. > >Section 7 - States that there are a list of objects and their sensitivity / > >vulnerability, but the list that follows only names the objects. No > >vulnerability > >information is

Re: [Softwires] WGLC for draft-ietf-softwire-map-mib-10

Hi, I’ve done a fairly extensive review of v10 of the draft. There’s quite a lot of comments, but nothing major. Thanks, Ian General Comments g1. 1, Introduction [if - RFC7597 only covers MAP-E. Translation is described in RFC7599. I think that this text is carried over from when MAP E and

Re: [Softwires] Review of draft-ietf-softwire-mesh-multicast-17

I had to forward this to the list separately as the original message was too large. I’ve removed any points which have been resolved. Cheers, Ian -- Hi Mingwei, Please see inline below. One additional comment that I found from reading —17: Section 4.4 - This states that the the AFBR

Re: [Softwires] ask for WGLC

Hi Mingwei, Thank you for your email. Checking the comments that were received during the last WGLC, there is: https://mailarchive.ietf.org/arch/msg/softwires/LT2ttfqUXw4IjwGFFBBrPMayoiU Please could you respond to

[Softwires] Review of draft-ietf-softwire-map-mib-09

Hi, Here is a review of the current version of the draft. Cheers, Ian Introduction a1) This needs to be updated: RFC7597 is for MAP-E and encapsulation is the single mode described there. RFC7599 deals with translation and so probably doesn’t need to be mentioned at all as it’s not part of

Re: [Softwires] WGLC For draft-ietf-softwire-mesh-multicast - Please respond by 23rd March

Suggest that it's broken into shorter paragraphs, or possibly number the diagram and then have the text as a corresponding numbered list. > On 09 Mar 2017, at 17:21, Ian Farrer <ianfar...@gmx.com> wrote: > > Hi, > > The authors of draft-ietf-softwire-mesh-multicast-15 believe th

[Softwires] draft-ietf-softwire-yang: Strawman Proposal to restructure the CE model

Hi, The structure of the model currently defined in draft-ietf-softwire-yang-01 provides a single model for ‘binding’ softwires containing BR and CE. We’ve done some work on implementing these models and whilst the BR model is working, the CE part is problematic. While there is all of the

Re: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017

Hi As a co-author, I support its adoption. We (DT) are currently testing an implementation of DHCPv4oDHCPv6 which includes the Source Address option with a plan to deploy. As this draft is predominantly concerned with changes to DHCPv4o6 client and server implementations, it seems logical to

Re: [Softwires] [dhcwg] I-D Action: draft-fsc-softwire-dhcp4o6-saddr-opt-06.txt

Hi Jinmei, May thanks for your comments. Please see inline. Cheers, Ian > On 18 Nov 2016, at 04:06, 神明達哉 <jin...@wide.ad.jp> wrote: > > At Wed, 16 Nov 2016 10:56:16 +0900, > Ian Farrer <ianfar...@gmx.com> wrote: > >> In advance of Friday’s presentation in

Re: [Softwires] Call for Adoption on draft-sun-softwire-lightweight-4over6-deployment-04

Hi, (co-chair hat off) I think this is a useful draft as an operator who is also deploying lw4o6. Thanks, Ian > On 16 Nov 2016, at 22:01, Yong Cui wrote: > > Hi folks, > > As you may know, we are going to close the wg soon. > So before we close it, we would like to

Re: [Softwires] Call for Adoption on draft-liu-softwire-lw4over6-dynamic-provisioning-02

Hi, (Co-chair hat off) As a co-author, I support adopting this work. We are currently working on implementations of the architecture and referenced RFCs/drafts described in this doc. Thanks, Ian > On 16 Nov 2016, at 22:09, Yong Cui wrote: > > Hi folks, > > As you

[Softwires] Fwd: IoT Directorate

Hi, Forwarding by request. Ian > > Forwarded Message > Subject: IoT Directorate > Date: Wed, 16 Nov 2016 23:59:41 + > From: Terry Manderson > To: i...@ietf.org > > Dear IETF, > > The interest in IoT technologies in the IETF,

Re: [Softwires] I-D Action: draft-fsc-softwire-dhcp4o6-saddr-opt-06.txt

Hi, In advance of Friday’s presentation in (and hopefully re-homing to) DHC. This version is a small update, adding some text about the creation of a dedicated IPv6 address to use as a tunnel endpoint. Thanks, Ian ___ Softwires mailing list

[Softwires] Fwd: Review of draft-ietf-softwire-map-radius-08

Hi, Here’s a review of the updated version of the draft. Thanks, Ian General Comments: Please do language review throughout. Throughout the document, there are multiple places where the client is described as sending a ORO containing the ’S46 container options’, or similar (e.g. Figure 1,

Re: [Softwires] Volunteers to review draft-ietf-softwire-dslite-yang?

Hi Med, Thanks for the reminder. I’ve been meaning to review this for a while. Cheers, Ian General Comments: 1, How does this draft relate to the model in draft-sivakumar-yang-nat? There seems to be a lot of redundancy between them, which is understandable given the respective functions of a

[Softwires] Results on WG Consensus question for IPR Disclosure on draft-ietf-softwire-dslite-multicast

Hi, A few weeks back I asked the WG their opinion on how to proceed with raft-ietf-softwire-dslite-multicast in light of the IPR disclosure. From the responses received, there is WG consensus to proceed with advancing the draft. Thanks, Yong & Ian

Re: [Softwires] PLEASE READ - IPR Disclosure question on draft-ietf-softwire-dslite-multicast - Respond by 18/10/16

range.com>> > Date: Tuesday, October 4, 2016 at 3:45 AM > To: Ian Farrer <ianfar...@gmx.com <mailto:ianfar...@gmx.com>>, softwires > <softwires@ietf.org <mailto:softwires@ietf.org>> > Cc: "draft-ietf-softwire-dslite-multic...@ietf.org >

[Softwires] PLEASE READ - IPR Disclosure question on draft-ietf-softwire-dslite-multicast - Respond by 18/10/16

Hi, A few weeks back, we sent out an question asking the WG their opinion on how to proceed with draft-ietf-softwire-dslite-multicast in light of the IPR disclosure. No responses to this question were received. According to RFC3669, in order for a draft with an IPR disclosure to advance there

[Softwires] IPR Claim on draft-ietf-softwire-dslite-multicast

Hi, Please be aware that an IPR disclosure has been submitted related to this draft: https://datatracker.ietf.org/ipr/2873/ In light of this, our AD would like to ask the WG’s opinion regarding the advancement of this I-D. Please can you respond by Friday 16th September. Thanks, Yong & Ian

[Softwires] Update to draft-sun-softwire-yang posted

Hi, We’ve just posted an update to the YANG model draft. It’s been quite a lot of time since 04 was published and so there are quite a large number of changes in this version based on numerous discussions and reviews. One of the major structural changes is the collapsing of MAP-T and MAP-E

Re: [Softwires] [softwire]The status of draft-sun-softwire-yang

Hi, Yes, it’s still being actively worked on and expect an update to be posted in the next day or two. Best regards, Ian > On 05 Jul 2016, at 17:39, Qiong wrote: > > Hi, > > It seems that the draft-sun-softwire-yang-04 has been expired for a period. > Just a question:

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

Hi, Thanks for making this update. Here is a review of this version. Cheers, Ian Overall The grammar/spelling and readability of the document throughout need to be checked and cleaned up. The terms MAP and S46 are used interchangeably throughout the document. It would be clearer if the

Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast

t the document and re-edited the language > and grammar. [if - I’m still seeing some problems with the above two points. I’ll reply you directly on these] > > > Best regards, > > Mingwei > > > > 发件人： Ian Farrer > 发送时间： 2016-04-20 03:53:13 > 收件人： draft

[Softwires] Fwd: Problem in draft-ietf-softwire-multicast-prefix-option

gt; Date: 8 June 2016 16:50:51 CEST > To: ian Farrer <ianfar...@gmx.com>, "softwires@ietf.org" > <softwires@ietf.org>, Jacni Qin <ja...@jacni.com>, "dxhb...@gmail.com" > <dxhb...@gmail.com> > Cc: "dhcwg-cha...@ietf.org" <dhcwg

Re: [Softwires] I-D Action: draft-ietf-softwire-unified-cpe-04.txt

gt; directories. > This draft is a work item of the Softwires of the IETF. > >Title : Unified IPv4-in-IPv6 Softwire CPE >Authors : Mohamed Boucadair > Ian Farrer > Filename: draft-ietf-softwire-unified-cpe-0

Re: [Softwires] WGLC on draft-ietf-softwire-unified-cpe-03

Hi folks, >> >> The authors of draft-ietf-softwire-unified-cpe-03 believe this document is >> ready for advancement. >> We would like to issue a working group last call starting from today to >> April 5th. >> >> Please send your substantial comments to

Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast

FC2119 language is revised throughout the document to avoid these problems and to tighten up the specification as a whole. The document needs the language and grammar checking throughout. > On 7 Apr 2016, at 16:58, Ian Farrer <ianfar...@gmx.com> wrote: > > Hi, > > This document ha

[Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast

Hi, This document has been around for some time, but has not received any substantive reviews. Can I ask for volunteers who are willing to provide reviews? Thanks, Ian ___ Softwires mailing list Softwires@ietf.org

Re: [Softwires] Review of draft-sun-softwire-yang-02

Hi Qin, Thanks for your comments. Please see inline. Cheers, Ian On 12 Mar 2015, at 08:53, Qin Wu bill...@huawei.com wrote: Dear all, I have read this document and think the softwire yang model is needed for the configuration and management of Softwire BRs and CPEs. A few comments

Re: [Softwires] lw4o6 question

HI Behcet, Thanks for pointing that out. Actually, I think that RFC2983 is the better reference, instead of RFC4213. As RFC2983 is informational, then this would move to being an informative reference (the current wording doesn’t use normative language anyway). Would that work? Cheers, Ian

[Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports

Hi, This one slipped my mind…. From a discussion with Ole during the MAP dhcp last call, there was a discussion about the exclusion of provisioning WKPs to CPEs - http://www.ietf.org/mail-archive/web/softwires/current/msg06010.html In previous versions, the lw4o6 used to reference

Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07

Hi Rajiv, Please see inline. Cheers, Ian On 1 May 2014, at 21:03, Rajiv Asati (rajiva) raj...@cisco.com wrote: UmmŠthat doesn¹t cut it either, since softwire node will always have to formulate the 32-bit IPv4 address even if /32 is conveyed. Also, Software interface is not defined

Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07

Hi Ole, So the whole paragraph would read: When receiving the Port Parameters option with an explicit PSID, the client MUST use this explicit PSID in configuring its softwire interface. The Port Parameters option with an explicit PSID MUST be discarded if the softwire node isn't configured with

Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07

Hi Ole, Please see inline. Cheers, Ian On 22 Apr 2014, at 15:17, Ole Troan o...@cisco.com wrote: Ian, And two comments on section 4.5: This section is entirely MAP specific, although the sub-option is generally applicable to all of the containers. while I think it is fine that it

Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07

Hi Ole, Old: When receiving the Port Parameters option with an explicit PSID, the client MUST use this explicit PSID in configuring its MAP interface. If the conveyed IPv4 address is not 32 bit-long, the option MUST be discarded. The formula for this check is prefix4-len + ea-len = 32

Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07

Hi, I have one question about the draft as it stands at the moment: Currently, OPTION_S46_BR is limited to only be a sub-option carried within one of the S46 container options (described in section 3). However, other softwire provisioning mechanisms also need this configuration parameter, for

Re: [Softwires] Proposed text that describes lw4o6 and map-e

Hi Woj, One thing about your propsed wording is that it reads like addressing independence and state reduction can be realised concurrently. What about the following (with some other slight language cleanups): Lightweight 4over6 is a solution designed specifically for complete independence

Re: [Softwires] Proposed text that describes lw4o6 and map-e

Hi Woj, Can we resolve this with the following wording change? Old: Lightweight 4over6 provides a solution with complete independence of IPv4 and IPv6 addressing (i.e., the IPv6 prefix does not embed an IPv4 address and/or port set). New: Lightweight 4over6 is a solution designed

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

. The full /128 prefix is then constructed in the same manner as [I-D.ietf-softwire-map]. --- - Original Message - From: Ole Troan Sent: 03/06/14 04:34 PM To: Ian Farrer Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt Ian, OK, so what about the following text? yes

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

Here’s the text that Woj mentioned: Lightweight 4over6 provides a solution for a hub-and-spoke softwire architecture only, where the lwAFTR maintains (softwire) state for each subscriber. [I-D.ietf-softwire-map] offers a means for optimizing the amount of such state by using algorithmic IPv4

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

It really depends on what you mean by 'the wheel' in this context… But, as a proposal, if we extend (and maybe rename) OPTION_L46_IPV4ADDRESS with new fields for prefix6-len and ipv6-prefixes to be used for a LPM, would this meet your definition of a wheel? Cheers, Ian On 5 Mar 2014, at

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

HI Woj / Simon, Below is some proposed text around interface and prefix selection for tunnel creation. @Simon, this changes some of the text that we previously agreed at WGLC, so please can you check it over? Cheers, Ian Well, so the text from the above discussion does not appear in the

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

...@viagenie.ca wrote: Le 2014-03-05 14:29, Ian Farrer a écrit : If the longest prefix match returns more than one matching prefix, then an implementation specific tie-breaker MUST be performed to return a single prefix. Does this mean that the lwB4 and lwAFTR would need to be from the same vendor

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

This could certainly save a spending the rest of the week micro-editing wording, so I’d be happy with it. An extremely tentative further suggestion: Should there be a draft which discusses the available softwire solutions more throughly (we would tackle this only after we’ve got the WGCLs

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

OK, it was merely a suggestion…. I’m mildly relieved I don’t have to write it. Ian On 4 Mar 2014, at 14:27, Ole Troan otr...@employees.org wrote: This could certainly save a spending the rest of the week micro-editing wording, so I’d be happy with it. An extremely tentative further

Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05

Reads as if there is only a single transport port allocated to the client. Wouldn’t something like ‘IPv4 address and a valid source transport port...’ be more accurate? I'll change it to: The source address and source port-range of packets resulting from the NAPT44 processing MUST

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

: Wojciech Dec wdec.i...@gmail.com Date: Wednesday, 19 February 2014 09:34 To: Ian Farrer ianfar...@gmx.com Cc: Softwires-wg softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt Hi Ian, Just to be clear: I'm ok with lw46 defining a specific functional

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

the highlighted part mean If the lwB4 receives an ICMP error message, if so can you replace it as suggested? I am not really sure why icmp identifier field is mentioned in there. Other than that I am ok with the text. Thanks Senthil From: Ian Farrer ianfar...@gmx.com Date: Monday, March 3, 2014 1

Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05

I support this moving forward, with a few small comments: 1, A few instances where packets' should be packet's throughout the doc (e.g. 8.2, 8.3) 2, Section 5.1 para 2, line 2 'as' is mis-spelt as “s”. 3, Section 8.1 The source address and port of the packet obtained as a result of the NAPT44

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

Hi Woj, Please see inline. Cheers, Ian On 16 Feb 2014, at 17:32, Wojciech Dec wdec.i...@gmail.com wrote: Hi Ian, you haven't replied on my high level comment - would appreciate if you introduced changes to that effect in the draft. Continued inline… [ian] The draft already contains

Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03

I also support it advancing, with the requested updates (as a co-author) Ian On 27 Jan 2014, at 20:02, Cong Liu gnoc...@gmail.com wrote: Hi all, I support advancing this document. Best Regards, Cong 2014-01-14 Suresh Krishnan suresh.krish...@ericsson.com Hi all, This message

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

Yiu L. Lee Ian Farrer Filename: draft-ietf-softwire-lw4over6-02.txt Pages : 20 Date: 2013-11-08 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over

Re: [Softwires] Thoughts on provisioning and universal CPE

Hi Cong, Please see inline. Cheers, Ian On 22 Oct 2013, at 14:42, Cong Liu gnoc...@gmail.com wrote: Dear Tom and all, I think this discussion is significant. 2013/10/18 Tom Taylor tom.taylor.s...@gmail.com (1) DHCP Provisioning of IPv4 Options