[07:02:44] arifumi joins the room
[07:02:57] tinnami joins the room
[07:03:01] fdupont joins the room
[07:03:16] hiromi.morita joins the room
[07:03:26] tomtaylor joins the room
[07:03:42] <tomtaylor> Agenda!
[07:04:02] <tomtaylor> Status
[07:04:44] <tomtaylor> 6rd approved, DS-lite coming along
[07:04:54] <tomtaylor> What is next for WG?
[07:05:33] Joonhyung Lim joins the room
[07:05:41] nmm joins the room
[07:06:39] <tomtaylor> Is there still interest in multicast?
[07:07:23] kawashimam joins the room
[07:08:32] <tomtaylor> Chris Matz: need multicast. Other approaches not sufficient. Not clear on use cases for IPv4. Prepared to help, report back to WG in Beijing.
[07:08:53] skudou joins the room
[07:09:25] <tomtaylor> Zhen? : prepared to present on multicast next meeting
[07:09:53] <tomtaylor> Yong Cui also interested
[07:10:38] satoru.matsushima@jabber.jp joins the room
[07:11:39] <tomtaylor> Hand count of willing reviewers: 6 hands
[07:12:11] <tomtaylor> Looking for volunteers to write multicast for 6rd. Got one.
[07:12:50] nordmark joins the room
[07:12:53] <tomtaylor> Basically, if we don't see progress by Beijing, will drop from charter
[07:14:46] <tomtaylor> draft-softwire-gateway-init-ds-lite: Status
[07:15:01] <tomtaylor> No charts on web, though he is displaying one
[07:15:24] <tomtaylor> IETF and 3GPP both making good progress
[07:16:07] <tomtaylor> Evolving the draft: how many gateways, how many AFTRs? Will clarify
[07:17:07] <tomtaylor> Mostly editorial and clarifications, but please speak up if you have other stuff to add
[07:17:44] bruno.stevant@gmail.com joins the room
[07:18:15] <tomtaylor> Will improve L3VPN over MPLS description if someone will help
[07:18:30] <tomtaylor> Multicast stuff to be added by volunteer.
[07:19:18] <tomtaylor> Joe Touch, draft-ietf-intarea-tunnels-00
[07:19:23] nmm leaves the room
[07:20:55] <tomtaylor> History: discussion began in Philadelphia. Capture known issues in tunnels, state
[07:21:07] <tomtaylor> Charts now showing: motivation
[07:21:43] <tomtaylor> Potential need for automation. MTU issue
[07:22:00] <tomtaylor> Chart: Observation
[07:22:21] <tomtaylor> Tunnels are L2, still subject to L2 issues
[07:22:42] <tomtaylor> Supposedly easier to change than other L2
[07:23:10] <tomtaylor> Also, when L2 aligns w/ L3, discovery and other easier
[07:23:41] <tomtaylor> Known issues: MTU, fragmentation, signalling, performance issues
[07:23:53] <tomtaylor> MTU discovery:
[07:24:17] <tomtaylor> Mechanisms: ICMP based vs. probe based
[07:24:52] <tomtaylor> Impact on E2E MTU discovery
[07:25:01] <tomtaylor> Fragmentation:
[07:26:18] <tomtaylor> Fragmentation at outer layer => reassembly at decapsulator. But could mean repeated frag/reassembly
[07:27:25] <tomtaylor> Fragmentation at inner level means destination reassembles -- performance benefits, but burden on destination.
[07:27:43] <tomtaylor> Signalling - ICMP etc
[07:28:31] <tomtaylor> How to determine there is a problem, how to locate it? Translation through tunnel
[07:28:46] <tomtaylor> State of RFC 2003 tunnels
[07:28:56] <tomtaylor> 2003 signalling
[07:29:12] <tomtaylor> State of RFC 4301 tunnels, quite different
[07:29:30] <tomtaylor> RFC 4301 signalling more constrained
[07:29:57] <tomtaylor> Fundamental questions: which tunnel model, which parties participate?
[07:30:51] <tomtaylor> Status of document: came out two years ago, lost from view due to formation of INTAREA WG. Would love to have more review and input
[07:31:17] <tomtaylor> Looking to revise and issue WGLC by September
[07:32:35] jinmei joins the room
[07:32:53] <tomtaylor> Shane (Level 3): Are the authors interested in effect of tunnels on routing and load distribution across the internet? Answer: would love to add a few paragraphs, but document is big already
[07:33:32] <tomtaylor> Chair: want to WGLC in Softwires?
[07:34:10] <tomtaylor> Answer: want input now, probably LC in INTAREA, announce Last Call to a number of other WGs.
[07:34:33] pselkirk@jabber.isc.org joins the room
[07:35:15] <tomtaylor> Principles: should always have MTU discovery, want positive acknowledgement that packets got through

[07:35:24] Mark Townsley joins the room
[07:36:15] karen.s.seo joins the room
[07:36:22] <tomtaylor> Document slanted more to analysis of issues than being a basic reference for other tunnel-oriented documents
[07:36:39] <tomtaylor> PCP discussion -- Dan Wing
[07:36:50] <tomtaylor> No slides
[07:37:23] <tomtaylor> Will attempt a new WG for PCP. Have chosen design of PCP this week.
[07:37:58] <tomtaylor> Supporting all the different scenarios that were presented before
[07:38:37] <tomtaylor> -----------------------------------------
[07:38:50] <tomtaylor> Now for some individual presentations
[07:39:08] <tomtaylor> draft-despres-softwire-6rdplus-00, Remi Despres
[07:39:11] <tomtaylor> Charts
[07:39:32] <tomtaylor> The need targeted by 6rd+
[07:39:56] <karen.s.seo> there don't seem to be any of the slide sets on the IETF78 web site -- where are they posted?
[07:40:17] Ole Troan joins the room
[07:41:02] <tomtaylor> Sorry, no time
[07:41:20] <tomtaylor> They will be posted shortly
[07:41:30] <karen.s.seo> Thank you.
[07:42:07] <tomtaylor> Diagrams showing different regions and paths through them
[07:42:49] <tomtaylor> Basic point: path optimization / minimization desiderata
[07:44:21] <tomtaylor> Site at top left: two 6rd hosts, V4P site, NAT44 CPE
[07:44:45] <tomtaylor> Diagram: address manipulations
[07:45:38] dudisaki joins the room
[07:47:15] <tomtaylor> These charts were apparently prepared for Anaheim, according to the subtitles. Check proceedings for IETF77
[07:47:49] <tomtaylor> Chart: functional differences from Teredo
[07:48:12] <tomtaylor> Teredo anywhere, 6rd+ requires operator support
[07:48:36] <tomtaylor> 6rd+ ensures connectivity with all types of CPE NATs
[07:49:06] <tomtaylor> With 6rd+, QoS of IPv6 controlled by ISP
[07:49:19] <tomtaylor> Chart: parameter acquisition by hosts
[07:49:51] <tomtaylor> Relationship with SAM
[07:50:34] <tomtaylor> What next?
[07:50:49] <tomtaylor> WG work item?
[07:51:23] <tomtaylor> Related: draft-lee-softwire-6rd-udp, draft-carpenter
[07:51:38] <tomtaylor> No questions to Remi
[07:51:43] <tomtaylor> ------
[07:51:59] <tomtaylor> draft-lee-softwire-6rd-udp-01.txt, Yiu Lee
[07:52:43] florin coras joins the room
[07:53:02] <tomtaylor> Power out
[07:53:27] <tomtaylor> Presenter trying to set up
[07:53:39] <tomtaylor> Power's back
[07:56:20] <tomtaylor> UDP encapsulation of 6rd
[07:56:29] <tomtaylor> Problem statement
[07:56:54] <tomtaylor> Objectives
[07:57:30] <tomtaylor> Basic thrust: minimize burden (changes) on CPE
[07:58:33] <karen.s.seo> slides for this have been posted
[07:58:42] <karen.s.seo> they're on slide 5
[07:59:21] <tomtaylor> Sorry, mind drifted, 
[07:59:29] <tomtaylor> Chart 6 "Cons"
[07:59:32] <karen.s.seo> slide 6 -- Cons
[08:00:20] <tomtaylor> Dan Wing waiting at microphone
[08:00:42] <tomtaylor> Chart 7 Working Items
[08:01:13] <tomtaylor> Questions and Comments
[08:02:17] <tomtaylor> Dan: Back up to slide 6 -- second bullet misleading. Overall thinks this is good initiative
[08:02:35] <tomtaylor> Agreed that addressing same problem as previous presention
[08:03:30] <tomtaylor> Philip Matthew: this would be VPN-like software added to host? 
[08:05:10] <tomtaylor> Remi Despres: slight difference in problem space: Remi's solution intended to minimize new hardware in core, this one minimizes changes in host
[08:06:07] <tomtaylor> Behcet Sarikaya: clarifications on effect on host
[08:06:29] <tomtaylor> All slides are now on the web
[08:07:03] <tomtaylor> Chair: this was discussed a couple of years ago, WG already has solution
[08:08:16] <tomtaylor> Chair: is there really value in solving this problem given time constraints -- will problem go away before solution is out?
[08:08:55] <tomtaylor> Chair: spoke to Chair of Homegate. 
[08:09:06] <tomtaylor> Lee: have to listen to operators
[08:09:37] <tomtaylor> Remi: this is not same problem as done already
[08:10:20] <tomtaylor> At microphone: what is the real problem?
[08:10:36] <tomtaylor> Lee: scalability concerns
[08:10:58] <tomtaylor> Remi: route optimization
[08:11:11] <Mark Townsley> There are absolutely L2TP softwire deployments. Multiple. 
[08:13:23] <Mark Townsley> So, if we make SP-managed Teredo, and we deprecate non-managed Teredo, our net sum will be the same number of mechanisms. That would be fine with me.
[08:13:35] <Mark Townsley> And 6rd could deprecate 6to4 at the same time.
[08:13:45] <tomtaylor> Stick to what we have already, don't take on new work. Operators are confused by multiple choices already
[08:13:57] <tomtaylor> Mark, should I be relaying this?
[08:14:32] <Mark Townsley> Yes, Tom, Feel free. And apologize to the group for not being present.
[08:15:12] <Mark Townsley> Teredo is not SP-managed. That's the operational difference from the SP perspective.
[08:17:24] nordmark leaves the room
[08:18:14] Simon Perreault joins the room
[08:18:15] nmm joins the room
[08:20:57] <tomtaylor> Chris, Cablelabs: problem worth solving, but prefer to stay with what has already defined
[08:21:10] <tomtaylor> Final statements by Lee and Despres
[08:21:37] <tomtaylor> -----------------
[08:21:57] <tomtaylor> draft-maglione-softwire-dslite-radius-ext-00, Roberta Maglione
[08:22:21] Shane Amante joins the room
[08:22:24] <tomtaylor> Background
[08:23:36] <tomtaylor> DHCPv6 based DSLite Configuration
[08:24:07] nordmark joins the room
[08:24:11] tinnami leaves the room
[08:24:17] <tomtaylor> RADIUS + above
[08:25:56] <tomtaylor> DS-Lite Tunnel-Addr Radius attribute
[08:26:20] <tomtaylor> DS-Litre-Tunnel-Name
[08:26:27] <tomtaylor> Questions?
[08:26:50] <tomtaylor> Presentation was also made in RADEXT
[08:27:58] simon.perreault joins the room
[08:29:15] <tomtaylor> Tina Tssou asking questions
[08:29:20] <tomtaylor> Tsou
[08:29:53] Simon Perreault leaves the room
[08:30:32] Wojciech Dec joins the room
[08:32:20] <tomtaylor> Chair polled: this work worthwhile? Fair amount of support. Will verify that this will be work item on mailing list
[08:32:39] <tomtaylor> draft-zhou-softwire-ds-lite-p2p-02, Yiu Lee
[08:32:47] <tomtaylor> Objectives
[08:33:04] <tomtaylor> Ideas
[08:33:22] tinnami joins the room
[08:34:04] <tomtaylor> 4 Architecture
[08:34:47] <tomtaylor> 5 Procedure
[08:35:49] <tomtaylor> 6 CPE Management
[08:36:20] <tomtaylor> Philip Matthew waiting at Microphone
[08:37:30] <tomtaylor> Will CPE hand out multiple private addresses in home? Yes. Does this have to go all the way out and in again?
[08:37:39] <tomtaylor> No.
[08:38:51] nmm leaves the room
[08:40:11] <tomtaylor> What if there are more than a million customers connected to a GW? Author not talking about mobile GW. Yes, > 1M, scalability issue -- address range
[08:44:05] nmm joins the room
[08:46:17] <tomtaylor> Modest support for this work
[08:46:44] <tomtaylor> draft-xu-softwire-tunnel-endpoint-01, Xiaohu
[08:48:15] <tomtaylor> Problem statement just done, now Our approasch
[08:48:26] Tina TSOU joins the room
[08:48:33] nmm leaves the room
[08:48:50] <tomtaylor> New extended community attribute
[08:49:05] <tomtaylor> Chart: avoid stacked tunnels
[08:49:16] <tomtaylor> Chart: aggregation
[08:49:40] <tomtaylor> Chart: conclusions
[08:50:11] <tomtaylor> Chart: next steps: looking for comments
[08:50:18] <tomtaylor> 3 people have read
[08:51:34] <tomtaylor> Why not use Tunnel Translation attribute? Sees it as valid for inter-AS
[08:52:51] <tomtaylor> Chair: to the list
[08:53:32] <tomtaylor> Another person asking why not RFC 5512? Please comment on list.
[08:53:52] <tomtaylor> draft-guo-softwire-6rd-ipv6-config-00, Xiaohu
[08:54:02] <tomtaylor> Chart 2: Scenario
[08:54:28] <tomtaylor> 3 Requirements for running DHCPv6 in 6rd
[08:55:18] <tomtaylor> 4 DHCPv4 option to carry DHCPv6 address
[08:55:30] <tomtaylor> 5 DHCPv6 in 6rd
[08:56:01] <tomtaylor> 6 Next steps: looking for comments
[08:57:11] tinnami leaves the room
[08:57:29] <Mark Townsley> DHCPv6 stateless using anycast BR Subnet Router Anycast 
[08:57:52] <tomtaylor> Discussion: multicast as efficient as unicast because hop-limited
[08:58:20] <Mark Townsley> That's what Ole was saying
[08:59:06] <Mark Townsley> Use the anycast router address of the RG
[08:59:21] <tomtaylor> To the list. First need to understand there is a problem to solve
[08:59:44] <Mark Townsley> Agree with Ralph.
[09:00:46] <tomtaylor> draft-cui-softwire-host-4over6, Yong
[09:00:52] <tomtaylor> Introduction
[09:01:01] <Mark Townsley> I do think it is a good thing to be able to support v6-only hosts, and I like solutions that reuse native IPv6 mechanisms as much as possible rather than diverging 6rd from native dual-stack.
[09:01:16] <Mark Townsley> That's my only hesitation with v6 options inside DHCPv4.
[09:01:33] <Mark Townsley> (no need to relay Tom, thanks)
[09:01:57] <tomtaylor> Chart: General idea ..
[09:02:15] HUI joins the room
[09:02:19] <tomtaylor> Chart 4
[09:02:25] <tomtaylor> Chart 5
[09:03:20] <tomtaylor> Chart 6 Stateless: DHCPv6 extension
[09:03:46] <HUI> Question:why avoid NAT64? or other XLATE?
[09:04:05] nordmark leaves the room
[09:04:09] tinnami joins the room
[09:04:09] nordmark joins the room
[09:04:33] dhankins joins the room
[09:05:07] <HUI> BIH+NAT64 is same as NAT44+ALG
[09:05:45] danwing joins the room
[09:05:48] <tomtaylor> 7 Stateless
[09:06:19] <tomtaylor> same chartnumber, adding info
[09:06:20] <HUI> You still need alg, how could avoid alg in nat44?
[09:06:59] <tomtaylor> 8 Stateless approach (CPE scenario)
[09:07:36] <danwing> they aren't NATting.  So no ALG.
[09:07:42] <tomtaylor> 9 Combination with dual-stack lite
[09:07:52] <tomtaylor> Host scenario
[09:07:53] <HUI> their ipv4 is public or private?
[09:08:03] <tomtaylor> same chart, more info
[09:08:18] <tomtaylor> 10 What Host 4over6 achieves
[09:08:35] <HUI> he made excuse and said that the reason don't use xlate is because alg, I don't see this excuse valid
[09:08:48] <danwing> slides are at http://www.ietf.org/proceedings/78/slides/softwire-9.pptx and slide 3 implies global IPv4 address.
[09:09:04] <danwing> The diagrams show "No 44 NAT" and "No 46 NAT" on several slides
[09:09:05] <tomtaylor> 11 Stateful approach of Host 4over6
[09:09:18] <danwing> he isn't NATting
[09:09:37] <HUI> so they are using public IPv4 address?
[09:09:51] <danwing> I believe so, yes.  That is my understanding.
[09:09:52] <tomtaylor> 12 Next step -- design team
[09:10:06] <danwing> Tom, can you relay Hui's question to the mic?
[09:10:19] <HUI> question:hey are using public IPv4 address?

[09:10:22] <tomtaylor> OK
[09:10:34] <danwing> (Tx, Tom.  I didn't want to stand up.)
[09:10:39] <tomtaylor> That is, are they using public?
[09:11:13] <HUI> yes
[09:11:14] <HUI> thanks
[09:12:12] <HUI> they are rich, thanks
[09:12:41] <tomtaylor> draft-matsuhira-sa46t-spec-01, Naoki Matuhira
[09:12:46] <HUI> you have public IPv4 address, you still need IPv6 tunnel
[09:13:01] <tomtaylor> Network configuration
[09:13:20] <HUI> this is waaste of Ipv4 address, 
[09:13:32] <tomtaylor> Function of SA46T
[09:13:54] <tomtaylor> SA46T address arch and routing'
[09:15:49] <tomtaylor> 5  Example of SA46T address format
[09:15:57] <danwing> @Hui: it's a way to provide IPv4 address to hosts that want/need it.  Presumably you could charge extra money to those hosts, or penalize them in some other way for consuming the scarce IPv4 resource.  But as we all know, there are drawbacks to IPv4 address sharing -- and that proposal avoids IPv4 address sharing.  You are, of course, correct that if the IPv4 address isn't shared, it is exclusively used by the host.  *shrug*.  It's a tradeoff.  Some times, that tradeoff has to be made (e.g., mail server and DNS servers can only listen on specific, and thus consumes an IPv4 address.)
[09:16:43] <tomtaylor> May I suggest taking that to the list?
[09:16:55] <tomtaylor> Configuration of SA46T
[09:17:07] jinmei leaves the room
[09:17:18] <HUI> excuse me , thanks dan's for discussion
[09:17:39] <tomtaylor> Host configuration
[09:17:44] <tomtaylor> Applicability
[09:18:12] <tomtaylor> Access Network with v4 addr reuse
[09:18:44] <tomtaylor> Current status and next step
[09:19:33] <tomtaylor> Chair: requires n(n-1) configurations? Essentially like static problem?
[09:20:10] <tomtaylor> How does this differ from softwire mesh?
[09:20:46] <tomtaylor> Should work on establishing relationship between this proposal and mesh
[09:20:54] <tomtaylor> No other comments
[09:21:29] <tomtaylor> raft-donley-softwire-dslite-flowlabel-00, Chris Donley
[09:21:47] <tomtaylor> QoS for DS-lite
[09:22:12] <tomtaylor> Hard for intermediate devices to classify traffic inside the tunnel
[09:22:41] <tomtaylor> There will be no time for the Boucadair presentation
[09:22:41] HUI leaves the room
[09:23:08] <tomtaylor> Chart: Use case: PacketCable Multimedia
[09:24:00] <tomtaylor> Chart: solution: use IPv6 flow label for classification
[09:24:41] <tomtaylor> Why not use Diffserv?
[09:25:03] <tomtaylor> - don't trust user to set
[09:25:30] <tomtaylor> - can't differentiate voice streams
[09:25:56] <tomtaylor> - proposed solution more consisytent with their model
[09:26:16] <tomtaylor> Request for feedback: useful for others?
[09:27:03] satoru.matsushima@jabber.jp leaves the room
[09:28:08] jinmei joins the room
[09:28:29] <tomtaylor> Shane Amante (Level 3): trusting 5-tuple, although user not trusted for DSCP. Contradiction? Answer: able to block misuse
[09:28:33] <Wojciech Dec> How can the operator distinguish, just by the flow lable, a voice call vs any other foo-bar traffic whose 5tuple gets mapped to the lable?
[09:28:39] fdupont leaves the room: Computer went to sleep
[09:29:04] <tomtaylor> Shall I relay, Woj?
[09:29:19] <Wojciech Dec> sure. Thanks Tom
[09:29:56] <tomtaylor> line at mic is 5 deep
[09:30:22] <tomtaylor> one gave up
[09:33:30] Jan Boogman joins the room
[09:34:37] <tomtaylor> Current topic is draft-donley-softwire-dslite-flowlabel-00, Chris Donley. No time for Boucadair paper
[09:35:56] <tomtaylor> Chair: is identification of traffic within tunnel important to WG?
[09:36:04] <tomtaylor> About 10 yes
[09:36:37] <tomtaylor> Shane: c oncerned about redefinition of flow label semantics
[09:37:10] <tomtaylor> This is more of a requirements document
[09:37:31] <tomtaylor> Dan Wing: want to identify flows
[09:37:51] <tomtaylor> Trying to use RFC 3697
[09:39:18] <tomtaylor> To the list
[09:39:42] <tomtaylor> Consensus this is a problem, not consensus on approach
[09:40:19] <tomtaylor> Will task some design teams for operational issues. Please E-mail chair to volunteer
[09:40:25] tinnami leaves the room
[09:40:26] tomtaylor leaves the room
[09:40:39] Joonhyung Lim leaves the room
[09:40:40] skudou leaves the room
[09:41:02] dudisaki leaves the room
[09:41:02] karen.s.seo leaves the room
[09:41:09] hiromi.morita leaves the room
[09:41:38] kawashimam leaves the room
[09:41:38] arifumi leaves the room
[09:41:42] florin coras leaves the room
[09:42:16] Ole Troan leaves the room: Disconnected.
[09:42:19] Wojciech Dec leaves the room
[09:43:30] dhankins leaves the room
[09:45:59] simon.perreault leaves the room
[09:51:39] nordmark leaves the room
[09:51:39] Shane Amante leaves the room
[09:52:00] florin.coras joins the room
[09:58:08] jinmei leaves the room
[09:58:30] pselkirk@jabber.isc.org leaves the room
[09:58:31] pselkirk joins the room
[10:00:32] Jan Boogman leaves the room
[10:01:57] bruno.stevant@gmail.com leaves the room
[10:06:40] Tina TSOU leaves the room
[10:07:39] simon.perreault joins the room
[10:07:44] simon.perreault leaves the room
[10:11:04] danwing leaves the room
[10:19:34] Joonhyung Lim joins the room
[10:46:40] arifumi joins the room
[10:49:22] arifumi leaves the room
[10:53:34] Shane Amante joins the room
[10:55:14] Joonhyung Lim leaves the room
[10:56:15] Shane Amante leaves the room
[10:58:23] pselkirk leaves the room
[10:59:34] florin.coras leaves the room
[11:00:16] Joonhyung Lim joins the room
[11:00:52] nordmark joins the room
[11:03:49] Joonhyung Lim leaves the room
[11:03:51] nordmark leaves the room
[11:19:58] florin.coras joins the room
[11:29:01] florin.coras leaves the room
[11:32:14] florin.coras joins the room
[11:53:08] florin.coras leaves the room
[12:02:31] dhankins joins the room
[12:02:47] danwing joins the room
[12:02:54] dhankins leaves the room
[12:11:24] danwing leaves the room
[12:13:18] danwing joins the room
[12:20:52] danwing leaves the room
[12:31:13] tony joins the room
[12:31:19] tony leaves the room
[20:43:04] Mark Townsley leaves the room
[20:44:25] Mark Townsley joins the room
[21:19:25] Mark Townsley leaves the room
[21:23:19] Mark Townsley joins the room
[21:55:30] Mark Townsley leaves the room
[21:57:17] Mark Townsley joins the room