[13:50:59] --- yjs has joined
[13:50:59] --- yjs has left: Lost connection
[14:00:01] --- amalis has joined
[14:00:18] --- yjs has joined
[14:00:25] --- sivaram7 has joined
[14:00:30] <yjs> hi everyone
[14:01:01] <yjs> starting now
[14:01:22] <yjs> Danny announced that anyone who hasn't sent in slides isn't going to talk today
[14:01:31] <yjs> Stewart and Matthew helping out
[14:02:05] <yjs> URL for presentations pwe3.tcb.net
[14:02:12] --- cpignata has joined
[14:02:31] --- mantakos has joined
[14:02:32] <yjs> agenda: charter update, status, generic PW discussion (problem statement)
[14:03:29] <yjs> Danny will be summarizing generic PW stuff
[14:04:13] <yjs> slide: list of updated/outstanding charter items (Apr 2006 - Mar 2007)
[14:04:24] <yjs> most looks good
[14:05:18] <yjs> 4 RFCs published, 5 in RFC editor queue, 4 in IESG processing
[14:05:51] <yjs> a lot of progress since the last meeting
[14:06:35] <yjs> correction - URL for slides: http://pwe3.tcb.net/meetings/ietf65/index.html
[14:07:26] <yjs> current WG status on the "tools.ietf.org/wg/pwe3" page
[14:08:32] <yjs> first presentation: Nabil Bitar Nabil Bitar first presentation: Nabil - ms-pw-requirements
[14:08:53] <yjs> draft was updated before Vancouver
[14:09:48] <yjs> restructured (now 5 sections: arch, use cases, req for placement mechanisms, OAM, security considerations)
[14:11:26] <yjs> comments from list: editorial (Ben from BT), VCCV end-end and segmental (Dimitri from Alcatel)
[14:11:51] <yjs> will reissue taking comments into account
[14:12:41] <yjs> next presentation: Matthew : ms=pw arch
[14:13:12] <yjs> brief update: in Vancouver became WG draft
[14:13:58] <yjs> many changes: strengthened text on NSP in S-PE, added congestion considerations, updated security considerations, removed sh-pw scaling issues
[14:15:15] <yjs> outstanding: NSP - do we need a list of compatible PW types (e.g. MPLS to L2TP)?
[14:15:58] <yjs> outstanding: security issues - is PW label spoofing a problem? (probably not as need type and SN)
[14:16:15] <yjs> next step - another revision and then WG last call
[14:17:18] <yjs> Sasha: need to address QoS since PSN header isn't intact end-to-end
[14:17:43] <yjs> Sasha: PW label spoofing is a big problem
[14:19:00] <yjs> Sasha: do you mean there is never an NSP in S-PE?
[14:19:19] <yjs> Matthew: shouldn't need to know PW types at S-PE
[14:20:03] <yjs> Danny: after req document, want to WG last call on this one too
[14:20:21] <yjs> please provide comments, LC in a few weeks
[14:21:02] <yjs> next Stewart on timing requirements
[14:21:14] <yjs> revision of a draft Tim Frost did a while ago
[14:21:36] <yjs> Not necessarily a "timing PW", just timing support for PW services that need timing
[14:22:02] <yjs> There are 3 aspects: frequency distribution, phase lock, and time alignment (wall-clock)
[14:22:50] <yjs> first 2 have traditionally been required here, 3rd needed by other apps
[14:23:07] <yjs> TDM and ATM(AAL1/2) PWs need frequency/phase
[14:23:18] <yjs> cellular backhauling need
[14:23:38] <yjs> Voice GWs, industrial apps, etc will also need, even if not PW centric
[14:24:07] <yjs> Requirements depend on application, e.g. GSM BST need 50 ppb timing accuracy
[14:24:28] <yjs> CDMA basestations need that + 10us phase alignment
[14:24:57] <yjs> G.8261 (formerly G.pactiming) defines requirements for TDM over Ethernet segments
[14:25:13] <yjs> in future they will consider IP and MPLS as well in ITU
[14:25:38] <yjs> more requirements: robustness, autodiscovery, security
[14:25:53] <yjs> may need HW assist
[14:26:19] <yjs> candidate solutions: adaptive clock as in TDM PWs, NTP, IEEE 1588
[14:28:28] <yjs> next steps: pick which protocol can be extended and where work should be done
[14:29:25] <yjs> Sasha: another requirement should be limited load on the network
[14:30:26] <yjs> Stewart - NTP is very low rate, 1588 v2 talks about 100 pps
[14:31:44] <yjs> Sasha: question - should we deal with HW support?
[14:32:29] <yjs> Stewart: there is evidence that without transparent clocks may be a problem
[14:34:45] --- dmm has joined
[14:34:53] --- OleTroan has joined
[14:35:01] <amalis> Yakov: NTP has a good protocol structure, the problem is the algorithmic part
[14:35:17] <amalis> There are few people that understand the clock issues, rather than the protocol issues
[14:35:38] <amalis> With 1588, they understand clocks but don't have the same protocol expertise
[14:36:09] <amalis> The question is - do we tell one of these groups to do the work, or should PWE3 try to take this on?
[14:37:23] <yjs> Mark: NTP WG is interested in doing new work, but are bogged down in v3 documentation
[14:37:43] --- todesgeliebter has joined
[14:38:14] <yjs> Mark: we need to help NTP WG to finish their work before they take new work on
[14:38:54] <yjs> Mark: NTP WG is chartered to collect requirements for new work
[14:39:13] --- dmm has left
[14:40:58] <amalis> Yakov: we need to specify a protocol can support the accuracy that we need - we shouldn't go any further than we need to.
[14:41:46] <yjs> Tom Nadeau - VCCV extensions - performance measurement
[14:42:12] <yjs> problem description: timing and performance measurement
[14:42:49] <yjs> performance measurement: PDV (+ distribution, sepctrum), packet loss, delay (rt, one-way)
[14:43:02] <yjs> do we need a requirements draft?
[14:43:09] --- todesgeliebter has left
[14:44:25] --- ted has joined
[14:45:42] --- dlewis has joined
[14:45:44] <yjs> Peter B (Lucent): major question is about packet loss - do we use probes or number packets?
[14:51:29] --- ted has left
[14:52:32] <yjs> Tom presents performance measurement and Yaakov presents timing over VCCV
[14:53:29] <yjs> Stewart: we need 2 requirements documents, 1 for performance measurement, 1 for timing
[14:53:50] --- dlewis has left
[14:54:03] <yjs> Chris Metz: attachment identifiers for aggregation and VPN autodiscovery (new name)
[14:55:09] <yjs> (co-authors : Luca, Florin, Jeff Sugimoto)
[14:55:45] <yjs> changes (other than new name): cleanup, AII type 1 (Bruce Davie draft in L2VPN)
[14:56:38] <yjs> Global ID in AII type 2 has been decided to be 4 octets (not 6) and holds AS number of provider supports global uniqueness
[14:56:44] <yjs> AII type 3 was removed
[14:57:32] <yjs> Danny - WG LC before the next IETF
[14:57:44] <yjs> Ping: there were more AII types in MFA
[14:58:17] <yjs> Chris: no plans yet, but will look into
[14:59:11] <yjs> Ping: PW protection
[15:00:33] <yjs> has been working on for a long time
[15:00:50] <yjs> originally thought that with fast reroute don't need protection at PW layer
[15:01:14] <yjs> but not all PWs are the same - some best effort and some protected
[15:01:29] <yjs> also, not all PWs will be backed up together
[15:01:55] <yjs> so there is a need for protection at PW layer so that some PWs will be protected more according to need
[15:02:37] <yjs> design: want both SS and MS PWs, so support FEC 129 and not 128
[15:03:01] <yjs> need to uniquely identify the working and protection PWs in the middle of the network
[15:03:41] <yjs> but use of AII/AGI not a good idea
[15:03:54] <yjs> need to have TLV that specifies which PW is for protection
[15:04:27] <yjs> determination of backup path. RSVP has ERO so no loop.
[15:04:56] <yjs> without ERO need switch point TLV
[15:05:06] <yjs> QoS is also optional here.
[15:05:44] <yjs> also need to specify 1:1 or 1:N protection - still not clear what this means
[15:06:15] <yjs> proposal: protection TLV
[15:06:42] <yjs> it specifies setup and holding preference levels, hot or cold stdby, 1:1/1:N
[15:06:53] <yjs> also has flags for fate-sharing and CAC
[15:07:19] <yjs> also a reference ID field to identify working and protection PWs
[15:08:07] <yjs> presents figure: edge nodes setup a MS-PW, edge node triggers protection, how it works is up to operator
[15:08:20] <yjs> failure detected via BFD
[15:09:29] <yjs> the procedures are different from present MS-PW procedures, and are OK for both SS and MS PWs
[15:09:45] <yjs> can this be a WG document?
[15:11:22] <yjs> Kireeti asks humorous question on whole idea
[15:11:51] <yjs> Peter asks why PSN layer protection not sufficient. Ping: prioritization at PW layer
[15:13:44] <amalis> Yakov: Only at the PW layer can we prioritize, but how many layers of priority are needed? If just a few, then it can be handled at the transport layer.
[15:14:03] --- amalis has left
[15:15:55] --- amalis has joined
[15:17:13] <amalis> Yakov presented draft-stein-pwe3-sec-req-00.txt
[15:17:56] <amalis> Many of the attacks in the drafts can be avoided if it is not possible to impersonate a PE
[15:18:48] <amalis> Yakov presented two of solution options:MD5 and an authentication TLV
[15:19:23] <amalis> He presented some problems with PW packet authentication, and a couple of options to fix those problems
[15:22:00] <amalis> Packet encryption is also an option, but requires hardware, and many encryption algorithms fail if any packets are lost
[15:22:26] <amalis> This can be fixed by using a per-packet key
[15:23:09] <amalis> Dave McDysan: He doesn't see the need for a separate requirements document
[15:23:33] <amalis> There's also relevance to the work in the L3VPN WG
[15:24:17] <amalis> He would like to see more alignment between the security requirements and mechanisms in this WG and the L3VPN WG
[15:24:40] --- OleTroan has left
[15:24:41] <amalis> Yakov: He saw that document after he wrote this one, and agrees that there is some basis for alignment
[15:26:17] <amalis> Yakov Rehkter: Why is MD5 not sufficient?
[15:26:42] <amalis> Yakov S.: It may be sufficient, but some people consider it too weak
[15:27:08] <amalis> .. or too much overhead
[15:27:47] <amalis> Yakov R: Many vendors have MD5 on their control protocols and don't complain about it being too much overhead
[15:27:55] <amalis> Yahkov R.: Why not use IPSEC?
[15:28:40] <amalis> Yakov S: These aren't IP packets, so you can't do IPSEC
[15:28:58] <amalis> Yakov R: Do you plan to use IKE?
[15:29:07] <amalis> Yakov S: One could
[15:29:59] <amalis> ?: For Ethenet PWs, why not use Ethernet security end-to-end?
[15:30:08] <amalis> Yakov S: That doesn't stop all attacks
[15:30:23] <amalis> Danny: This is not a WG draft, but useful work
[15:31:02] <yjs> Yang (Huawei): group protection
[15:31:41] <yjs> since many PWs may fail together, why not protect a group of PWs together?
[15:32:06] <yjs> not sufficient to protect the tunnel since this is limited to single operator domain
[15:32:49] <yjs> group protection can give faster protection
[15:33:10] <yjs> and lower BW since only one OAM channel
[15:33:56] <yjs> whole group can be switched at S-PE into another PSN tunnel
[15:36:17] <yjs> Yang: MS-PW OAM
[15:37:15] <yjs> capability negotiation - reserve 1 bit for CV type (instead of 3 bits in original versions)
[15:38:13] <yjs> added FDI and RDI functions. Need a bit in CW
[15:38:42] <yjs> detection of misconnection via OAM PDU
[15:39:16] <yjs> next step - performance monitoring
[15:44:25] --- sivaram7 has left
[15:46:27] <yjs> Peter B: BFD is sufficient for misconnection
[15:47:04] <yjs> Yaakov S: statement that need bit in CW is unclear - is this data or OAM packets
[15:47:17] <yjs> Rahul: overlap with work done in BFD WG
[15:48:14] <yjs> Dinesh: CW in VCCV - is this the right mechanism, or should we use router alert mechanism
[15:49:03] <yjs> Dinesh: functionality has been defined elsewhere. If LSP ping and BFD not sufficient take a look at Ethernet OAM.
[15:49:55] <yjs> George: BFD has ability to MS FDI (called concatenated channel down), but no RDI (but could be added)
[15:50:31] <yjs> Rahul: I think it is possible to add to BFD if small changes. BFD WG is not yet closed.
[15:50:40] <yjs> Stewart: BFD WG is about to close.
[15:51:51] <yjs> Linda: if FDI needed then need BFD change. Do we need to agree on this first?
[15:52:30] <yjs> George: want to extend router alert method as much as possible
[15:53:00] <yjs> Peter: already have RDI in BFD and PW status.
[15:54:17] <yjs> George will give a short talk on wildcard PW type draft
[15:54:53] <yjs> since less info, security suggestion that you shouldn't respond to a wildcard unless configured specifically
[15:55:06] <yjs> want to finish off - need comments
[15:56:25] --- cpignata has left
[15:56:42] --- yjs has left
[15:57:25] --- mantakos has left
[15:57:27] --- amalis has left
[16:10:06] --- sivaram7 has joined
[16:10:15] --- sivaram7 has left