[11:06:02] --- xrtc has joined
[11:06:32] --- xrtc has left
[13:51:19] --- jinmei has joined
[14:00:30] --- gdweber has joined
[14:04:49] --- cpignata has joined
[14:05:02] --- nm has joined
[14:05:39] --- FDupont has joined
[14:06:51] <jinmei> interim meeting summary
[14:07:03] <jinmei> notes: http://bgp.nu/~dward/softwires/2006-02SoftwiresinterimNotes.html
[14:07:54] --- OleTroan has joined
[14:09:11] <jinmei> conclusions
[14:09:16] <jinmei> l2tpv2 as pharse 1 solution for H&S
[14:09:38] <jinmei> l2tpv3 as phase 2 solution for H&S
[14:09:45] --- mantakos has joined
[14:10:52] <FDupont> http://bgp.nu/~dward/softwires/2006-02SoftwiresInterimNotes.html (fixed URL)
[14:11:49] <jinmei> conclusions 2
[14:12:08] <jinmei> proposed third interim meetnig in 'september': discuss framework for phase 2 H&S
[14:12:29] <jinmei> finalize extension set for mesh
[14:12:54] <jinmei> thanks to hosts and Mark for hong kong meeting
[14:13:49] <jinmei> consensus
[14:13:58] <jinmei> given that:
[14:14:08] <jinmei> - there was discusssion involving many wg participants
[14:14:16] <jinmei> - no open issues considered remaining
[14:14:36] <jinmei> - solution providers will represent a common vision in next presentations as stated in interim meeting notes and conclusion
[14:17:10] <jinmei> declared rough consensus: L2TPv2/v6 for H&S, MPBGP for mesh
[14:18:45] <jinmei> Mark: many discussions in DT on the list, we have consensus
[14:19:10] <jinmei> (disclaimer: this log is very incomplete. it's hard for me to catch all conversation in a timely fashion)
[14:22:36] <jinmei> short presentation about china BB: 10-100Gbps, ipv4 over ipv6, various issues about financial/political things
[14:28:26] --- inet6num@jabber.org has joined
[14:28:42] <jinmei> -------(lost context: requirement summary?)
[14:28:53] <jinmei> what is needed:
[14:28:59] <jinmei> softwire tunnel discovery
[14:29:06] <jinmei> multi-AF/SAF reachability
[14:29:24] <jinmei> way to associate AF/SAF reachability to the softwire
[14:29:27] <jinmei> softwire tunnel encaps
[14:32:46] <jinmei> other requirements to consider 1 scalability AFBR peering: O(# of peering AFBR + #of cpe routers) AFBR routes: O (global internet + #AF?SAF island prefixes) af/saf reachability not limited to VPN AF/SAF combinations must support tunneling of any af/saf combination softwire encaps must support different encaps possible for afbr to support more thatn one encap type (eg GRE, ipsec) and express a preference for one different AF/SAF prefixes may use different encaps multicast support native AF/SAF multicast routing/forwarding across single AF transit network
[14:33:55] <jinmei> use existing protocols where possible eg reuse the HS encap time to market consider what is already deployed
[14:35:01] --- jjmbcom has joined
[14:35:27] <jinmei> solution framework 1: basic idea leverage and reuse existing protocols where appropriate MP-BGP, L2TP, v4 in v6, MPLS,... extend MP-BGP to enable egress AFBR to advertise their softwire tunnel capabilities, encapsulation parameters and preferences to participating AFBR nodes... thus forming the softwire mesh connect AF/SAF reachability to a softwire
[14:38:31] <jinmei> solution framework 3 (notes) general AF(i) over AF(j) solution must support any AF/SAF combination like ipv4-over-ipv6 leverage existing tunnel signaling machinery where appropriate
[14:40:39] <jinmei> MP-BGP notes comes with scalability, interoperable multi-AF/SAF reachability deployments (rfc4364) and policy controls softwire tunnel extensions: afbr express softwire support using BGP capabilities egress AFBR announces softwire tunnel types, encap parameters and preferences associate AF/SAF reachability with softwire and be as efficient as possible tunnel SAFI is one possibility: tunnel encapsulation attribute defines tunnel type/encap/preference and is carried by MP-BGP
[14:41:30] <jinmei> softwire encapsulation possibilities (over ipv4 transit) IP, UDP/IP, GRE, IPsec, MPLS, L2TPv3
[14:42:32] <jinmei> consensus actions from hong kong meeting agreed to merge two efforts wu-softwire-4over6-00 & BGP tunnel SAFI+ presentation
[14:43:24] <jinmei> mesh framework AFBRs use MP-BGP to announce softwire establish baseline set of IP(x)-over-IPy encaps present softwire mesh framework in dalls (done:-) commence effort on mesh framework draft after dalls ietf build on tunnel safi notion in wg with review
[14:44:18] <jinmei> next steps softwire mesh framework draft supporting mp-bgp softwire tunnel drafts tunnel safi idea support for ipsec control/encap tie in to the multicast effort eg draft-ietf-softwires-4over6vpn
[14:45:13] <jinmei> pekka savola: seems to have assumption about nature of border routers.
[14:47:11] <jinmei> -> you could certainly have v6 access island. and number of islands into the transit layers. given limited l2IF, may not scale well as L3 mechanisms. (came up in interim as well) take advantage of other tunneling mechanisms
[14:47:29] <jinmei> Pekka: (rephrasing) possible to mechanism that wouldn't require dual stack?
[14:50:11] --- farinacci has joined
[14:50:17] <jinmei> someone: don't need to configure tunnel?
[14:50:27] <OleTroan> Jerome I think
[14:50:28] <inet6num@jabber.org> someone = Jerome Durand ;)
[14:52:08] <jinmei> Jerome: complexity seems the same. don't see the benefit(?). need to read the doc.
[14:53:21] <OleTroan> assumption is that you already have a BGP infrastructure in your transport network that you can reuse.
[14:55:19] <jinmei> L2TPv2 hubs & spokes for phase I: mMaria Alice Dos Santos
[14:56:41] <jinmei> L2TPv2 vs TSP at softwires interim meeting inhong kong, multiple protocol have been proposed at interim meeting, non-technical requirement evalution for the proposed protocols was conducted technical comparison between l2tpv2 and tsp has been conducted and discussed on ML wg selected L2TPv2 as the phase I hubs and spokes solution based on the comparison results of the following categories
[14:56:44] --- farinacci has left
[14:58:00] <jinmei> standardization status L2TPv2 (RFC2661) has been standardized since 1999 TSP has been sent to the RFC editor as individual submission
[14:59:56] <jinmei> interoperability L2TPv2 protocol has been proven by numerous independent/interoperable implementations router vendors/linux posix-based OSs/CPE/native MS windows client/downloadable winXP client/GPL source code one TSP server...
[15:01:47] <jinmei> pekka: 1. call setup phase 100 sec. it means rebooting takes for a while. 2. don't understand on TSP implementations. there are independent implementations of TSP servers.
[15:03:04] <jinmei> pekka: a university has an implementation of TSP. Tim chown: (lost)
[15:03:33] <jinmei> any numbers of v6 over v4? => no.
[15:04:12] <jinmei> deployment experience L2TPv2 deployment experience NTT, etc TSP deployment expereince KDDI, NTT, AT&T
[15:06:06] <jinmei> OAM L2TPv2 standardized accounting and MIB l2tpv2 uses in-band signaling l2tpv2 control plane stays for the life of tunnel l2tpv2 high-availability TSP has no std. accounting and MIB TSP uses in-band signaling TSP ... comments: TSP has some MIBs actually for some accounting purposes
[15:07:25] <jinmei> pekka: first comparison is not fair. L2TPv2 is so complex and unclear how IPsec is applied maria: don't think so. TSP will also need such doc.
[15:09:15] <jinmei> authentication/security L2TPv2 std full tunnel protection with ipsec built-in mutual tunnel authentication data encapsulated in session header with tunnel/session TSP no security or encryption draft or std specified for TSP TSP supports mutual authentication TSP uses IP-in-IP (protocol 41) encapsulation, 'easy to spoof' (RPF check is to be used)
[15:13:04] <jinmei> Marc Blanchet: you could use whatever you want. Alice: also cover control plane? => yes. Alice: not specified in the TSP draft. Marc Blanchet: it's done somewhere else. Alice: The only missing part is data plane security? (note: not cover all comments)
[15:16:10] <jinmei> Mark: problem statement mentions the security for both data and control with IPsec. Pekka: put it also other way. even if you want to require data security, for L2TP you'll need ipsec because there is no other way. TSP can use other techniques
[15:18:57] <jinmei> someone: we have rough consensus: it was very very very rough. needed more discussion on ML. TSP has more current deployment. I'd like to get confirmation for people here that this is actually consensus
[15:20:07] <jinmei> Tim Chown: (question is lost) Alice: L2TPv2 runs over UDP. not a problem.
[15:23:04] <jinmei> Miyakawa: about nat traversal, both can do that. (go back to the interoperability slide). my team had done both. still going to do trials. lots of details are discussed. from users' point of view, as long as it can be done, we can use it. we also implemented TSP clients. we found from user's point of view, either is fine. point is whether vendors will implement it. negotiated with other vendors (can't be disclosed). Japan is maybe one strong country about v6, don't think the comparison about today's deployment is good. everyone is doing their experiment. important thing is how many vendors will implement it. competition is necessary.
[15:24:53] <jinmei> v6 over v4 softwire with L2TPv2: case 1: host CPE as softwire initiator IPv6CP: capable of /64 interface ID assignment or uniqueness check ISP to dual AF host CPE auto-config DHCPv4 can be used for DNS
[15:25:50] <jinmei> case2: CPE as initiator ipv6cp: capable of /64 interface ID... case3: host behind CPE as initiator ipv6cp: capable of /64 ifid assignment
[15:26:07] <jinmei> case 4: router behind CPE as softwire initiator
[15:26:39] <jinmei> cases with L2TPv2 (too fast to catch)
[15:27:16] <jinmei> v6/t2tpv2/v4 today NTT www.ntt.com/release_e/news05/0011/1121.html point6 cisco
[15:28:13] <jinmei> Miyakawa: case1. we're not doing RA for this. we use DHCPv6 for PD anyway. host will still assign the address based on the allocated prefix.
[15:28:25] <jinmei> Alice: it's just a potential model.
[15:29:14] --- nm has left: Replaced by new connection
[15:29:14] --- nm has joined
[15:29:14] --- nm has left
[15:30:06] <jinmei> Miyakawa: still wondering prefixes assigned via DHCPv6 PD can be used on loopback, etc. that still works. looks like some router that has no address. [lost]. if we can use one /64, it will save address space
[15:31:04] <jinmei> Miyakawa: has various experiments. to be fair, done the same thing for TSP.
[15:32:11] <jinmei> : v6 over v4, transition tunnel, host is not allowed to
[15:32:17] <jinmei> (lost Mark's point)
[15:33:02] <jinmei> L2TPv3 proposed as phase II H&S softwire standard L2TPv3 is a superset of L2TPv2, with enhancements in security, scalability and flexibility for future extensions
[15:33:34] <jinmei> L2TPv3 for the future v4 or v6 header UDP + L2TP version session ID (32bits) cookie (up to 64 bits, optional) payload
[15:34:48] <jinmei> why move to L2TPv3? improvements stronger tunnel authentication mechanism built-in lightweight data plane security more efficient header encapsulation 32bit flat session ID, more efficient lookup in forwarding plane runs over either IP or UDP L2TPv3 can tunnel IP directly w/o PPP reduce tunnel/session setup time
[15:36:12] <jinmei> phase II H&S with l2tpv3 L2TPv3 H&S framewrok draft to be deliverd in nov. 2006 document/recommend/define L2TPv3 H&S softwire solution implementation specifics additional potential items for phase II dhcp integration softwire concentrator auto discovery IP over L2TPv3 solution NAT discovery mobility and nomadicity
[15:36:18] <jinmei> (slides end)
[15:37:11] <jinmei> Marc Blanchet: (go back to 'why move to l2tpv3'?) is this a consensus or proposal? Alice: proposal, but no objection.
[15:37:23] --- mantakos has left
[15:37:32] <jinmei> David: based on consensus for phase II
[15:38:31] <jinmei> Marc Blanchet: what does NAT discovery mean? nat between home and ISP. right now L2TPv3 will discover which encapsulation it uses.
[15:40:23] <jinmei> Marc: TSP supports NAT discovery. it's very important for today's deployment.
[15:42:13] <jinmei> David: any selection by WG will not prevent other mechanisms. that being said, I'd like to know how many think we can move with the current consensus.
[15:43:21] <jinmei> David repeats the question: how many people think we have achieved consensus and can move with L2TPv2?
[15:44:45] --- brabson has joined
[15:46:44] --- nm has joined
[15:46:50] <jinmei> many people raised their hands
[15:47:14] <jinmei> (there seems to be clear consensus in the room)
[15:48:39] <jinmei> Fred Templin IP tunneling and MTU
[15:48:42] --- mantakos has joined
[15:49:06] <jinmei> problem statement IP in IP tunnels span multiple L2 segments but are seen by L3 as ordinary links common tunneling...(lost)
[15:49:47] <jinmei> problems with v4 fragmentation no mechanism for determining decapsultor's MRU network-based v4 fragmentation has negative impact on performance v4 fragmentation can result in black holes when firewalls/NATs in the path
[15:50:10] <jinmei> problems w/ ipv4 PMTUD icmpv4 fragmentation needed messages can be spoofed...
[15:50:22] --- gdweber has left
[15:51:38] <jinmei> Requirements for new mechanism 1. tunnel endpoint negotaiton 2. backward compatibilty with v4 fragmentation; ipv4 PMTUD 3. above -ipv4 host based segmentation at the encapsulator 4. (lost) 5. packet splicing error detection 6. accommodate out-of-order delivery 7 means for encapsulator to probe PMTU 8 means for decapsulator to send authenticated probe response 9 proactive path probing to determine best MTU 10 (lost)
[15:52:53] <jinmei> summary existing tunnel mechanisms have no means of assuring tunnel MTU most problematic for tunnels that traverse NATs; firewalls tunnel MTU assurance needed for tunnels that span NATs; firewalls
[15:53:17] <jinmei> Question: worth considering? some raised hands.
[15:54:29] <jinmei> next steps
[15:54:34] <jinmei> Deliverables general docs security analysis radius accounting mesh framework doc using MPBGP multicast draft extensions tunnel-safi and any additional softwires attributes to be reviewed by L2VPN, L3VPN, IDR... H&S phase 1 framework doc using L2TPv2 phase 2 framework doc using L2TPv3 extensions
[15:55:25] --- brabson has left
[15:56:03] <jinmei> next deliverables july 2006 security analysis radius accounting mesh framework doc using MPBGP mesh multicast draft ext. mesh tunnel-safi and any additional softwires attributes HS phase 1 framework doc using L2TPv2 potential interim WG meeting sep 2006 nov 2006 march 2007 H&S phase 2 ext
[15:58:58] --- SAN has joined
[16:00:11] --- OleTroan has left
[16:00:13] --- SAN is now known as SAM
[16:00:17] --- SAM has left
[16:00:36] --- cpignata has left
[16:01:04] <inet6num@jabber.org> thanks for the notes Jinmei
[16:05:45] --- inet6num@jabber.org has left
[16:08:38] --- jinmei has left
[16:18:02] --- nm has left
[16:24:11] --- FDupont has left
[16:24:40] --- nm has joined
[16:41:01] --- jinmei has joined
[16:41:14] --- jinmei has left
[16:48:13] --- jjmbcom has left
[16:48:26] --- mantakos has left: Replaced by new connection
[16:48:27] --- mantakos has joined
[16:58:39] --- nm has left
[17:14:10] --- mantakos has left
[17:23:28] --- mantakos has joined
[17:34:09] --- mantakos has left: Replaced by new connection
[19:12:59] --- juha.wiljakka has joined
[19:13:27] --- juha.wiljakka has left