TUESDAY, November 7th, 2006 - 1740-1840 & 1850-1950 ----------------------------------- CHAIRS: Danny McPherson (danny@tcb.net) & Stewart Bryant (stbryant@cisco.com) Minutes: Matthew Bocci (matthew.bocci@alcatel.co.uk) Administrivia ------------- PWE3 congestion moved to later until transport ADs arrive. draft-mohan moved to end because extended discussion expected. WG Status and Update - Chairs ----------------------------- A number of RFCs are being published. Expired MIB drafts: authors need to make the current. SONET in IESG processing. Held up on security issue around UDP / IP. TDMoIP also held up on some edits on UDP text Cell transport with AD. FC encap draft liaised to transport ADs for comments on congestion handling. MS-Arch and AII aggregate in WG LC. MS-PW requirements completed WG LC. Fibre Channel frames Over MPLS - Ronen Solomon (RonenS@corrigent.com) --------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-03.txt Just posted 2nd version of draft. Includes a reliability protocol. - Reliable congestion control - Updated encap format - Added signalling TLVs Congestion control includes TCP friendly rate control. Describes details of the protocol. Based on LAPB using selective retransmission. Reliable: sequencing and re-sequencing mechanisms, and ACK from far end. Lost frames are retransmitted. 2 types of frames: I-frame (info frame) carries FC data. S-frame is supervisory frame. 3 types: receiver ready, receiver not ready, selective reject. S- frames should be sent as high priority. Parameters include T1 poll timer, response timeout, window size, and retransmission timer. Shows FC LABP encapsulation Control word is required. Does not supports fragmentation Shows the Type I and Type S LAPB headers. Describes the signalling parameters. Needs to assign new PW type: FC port mode Assign parameter ID for interface parameters. Yaakov Stein: how many bits do you use for sequencing? We had sequence numbers twice for TDM. So you could do a fast look up. Ronen: just reusing existing method Yaakov Stein: might want to look at TDM method Stewart Bryant: is 16 sequence number enough? Ronen: Yes, for the window we use. Includes any normally expected transient in the network. Pseudowire Security - Yaakov Stein (yaakov_s@rad.com) ----------------------------------------------------- http://www.ietf.org/internet-drafts/draft-stein-pwe3-pwsec-00.txt Last 2 times we met, talked about sec requirements. This is a new doc proposing some solutions. Requirements expired, so will refresh. This mechanism should solve problems in the user plane confidentiality, integrity, source info. 802.1ae in IEEE published MACSec. This is based on AES, and uses GCM (Galois Counter Mode) MACSec adds a new tag in the Eth frame - Sec Tag - includes an identifier and optional secure data, plus an ICV (integrity) and a new FCS. This gives encryption, integrity and source authentication. Sec Tag has New Ethertype, 4 B packet number, 8B secure channel ID. Forms a 12B Initialization Vector. New GCM mode relies on state of the art AES-128 Uses counter to thwart replay attacks. ICV verifies payload integrity. Single encryption algorithm. Can to authentication without encrypting. Data not in packet payload can be authenticated too. IV nonce can be any length. Algorithm can be efficiently implemented in software Computation can be parallelized for high speed Unencumbered by IPR claims. Adopted by 802.1ae for MACSec and RFCs Shows: Encryption input, output, & decryption input and output Proposes a format for PWsec Standard packet with tunnel and PW label and control word. These are followed by IV, encrypted payload, and ICV. This format gives encryption and integrity. Use of PW sec needs to be configured at PEs, or signalled using a new TLV IV should be chosen pseudo-randomly Source authentication could use PE ID + AI, or if LDP is authenticated can use PW label + SN. Suggests that we should look carefully at this method because it gives all protections required Sasha Vainshtein: There are security issues related to PWs, and ones related to transport. E.g. confidentiality is transport and not a PW problem. Yaakov: this is at payload level, so it is a problem for PW Sasha Vainshtein: if P router is compromised and PW level is not encrypted, enemy can learn info to do attacks. Sasha Vainshtein: starts from point that you learn valid PW label. This is not encrypted. How you use it is another issue. Sasha Vainshtein: encryption should happen above PW level. Yaakov: client can do this end to end Sasha Vainshtein: how is this going to work with MS-PWs? Yaakov: currently addressing single operator domain with trust between both ends. If you have a multi-domain then S-PE needs to do this Danny: need to scope to cover multi-segment Stewart: did you say this is not in scope? Sasha: some attacks look to be beyond scope of the PW Danny: encourages feedback on this Don O'Connor: also doing 802.1af managing session keys on the fly. You need to continuously change session keys Yaakov: we have own mechanisms Don: might make sense to VPWS to do encryption end to end Bruce Davey: shy doesn't PE-PE IPSec meet requirements? Yaakov: where do you put it in MPLS? This looks like a better match than building whole IPSec mechanisms. Bruce: So you cut out IP header. Also , what's key dist mechanism? Yaakov: didn't go into that yet. But can use a couple of mechanisms. ?: This proposal is for PW only. Can we not look at this for MPLS in general? Yaakov: not saying it couldn't be done, but we are in PWE here. ?: Not clear if source authentication means ingress PE, or which specific PE who sent this packet. Yaakov: Packet claims by identifier which PE / AC it came from. Shane Amante: does IEEE have an answer for load balancing for this? Yaakov: LAG won't work here. That's an Ethernet question. Luca Martini: Don't think it is a good idea to add extra layers for encryption. If you do IP Sec, you loose association between PW and routing protocol. In most cases, people want to encrypt just some PWs. So see this as a much better solution. Danny: need to solidify requirements in WG. This is work of merit. Mark Townsley: Talking to security AD. RFC4017 gives BCP guidelines for key management. Concerning when people do own security, but would like to see draft. Need to get early review for this. Stewart: please can we have an adviser from security area. Dotting the 'I's - Yaakov Stein (yaakov_s@rad.com) ------------------------------------------------- No draft. Spotted some inconsistencies in current RFCs: - This is resolved. Pseudo wire, pseudo-wire, etc. Changed to Pseudowire emulation. - RFC4385 and atm-encap problem. There is no way to negotiate not to use a sequence number when you have a control word. Perhaps negotiate means send a 0, but this conflicts with interpretation of in-order. - FEC 128 vs 129: we have 2 FECs. Some applications use one or the other. What happens if you have PE with 128 and 129 at other end? Or worse a PE that supports both talking to one that only supports one? Perhaps should have a capability exchange? - Definition of forwarder: 4447 and 3985 appear to have different definitions. - 3985 explanation for forwarder further confuses things. Proposals: - remove sentence about negotiating sequencing number from atm-encap, - remove 4385 text in an erratum - 3985: ... Sasha Vainshtein: in definition of forwarder, don't remember lower picture showing 1-1 mapping from forwarder to PW instance. Think you are wrong. A VPLS, VSIs are forwarders. Forwarders are not always ACs. Danny: take to list. Sasha: great you have dotted the i's, but this is the wrong i Luca Martini: Sequence number was supposed to mean that if you advertised a label and received 100 packets with 0, and then received a non-zero, then this is an error. Stewart: need a discussion on list Luca: for FEC. no issue. This capability is per-PW. Danny: take this to the list. Stewart: Mark just moved cell transport to IESG eval, and it is on the agenda for the telechat of 16 Nov. IEEE 802.1ah Mode for Ethernet Over MPLS - Cao Wei (caiwayne@huawei.com) ----------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-cao-pwe3-802-1ah-00.txt Shows motivations. 802.1ah and PBT are emerging: TE, simple, scalable, deployment is forthcoming. Current PWE3 does not fully match requirement for 802.1ah. NSPs should be considered for .1ah Shows a scenario with a .1ah domains interconnected across MPLS network. Raw mode could support this, but using .1ah can process B-tag / i-tag for PW multiplexing, and PW switching based on B-tag / I-tag New PW mode is defined Lists new interface parameters Next steps: improve document and consider issues about MS-PW and 802.1ah Sasha Vainshtein: RFC4448 explained tagged/raw mode. Difference is how you push/pop service delimiter. What exactly does new mode add to this? Ali Sajassi: .1ah frame format looks identical to .1ad to transit nodes. With B tag, can use existing mechanisms. Why do we need a new type? If you want to do it on a I-tag, what is the scenario for distribution based on i-tag. Vach Kompella: What is the NSP that you need? Are you processing the tag? If so, that is out of scope. Sewart: agreed, but need to look at requirements Yakov Rekhter: If you could use B/I tags to identify PWs, what is the problem you are trying to solve? No shortage of MPLS labels in practical deployments. Needs to be a requirements doc. Stewart: need a clear agreed statement of what problem you are trying to solve Dave Allan: number of end points associated with isid in mulicast will reduce overall multicast load across MPLS network. Stewart: please separate requirements from solutions PWE3 Congestion - Bruce Davie (bdavie@cisco.com) ------------------------------------------------ http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-04.txt Been around for a couple of years. Stewart at last IETF. v4 of the draft. Re-spin as a framework draft. Try to examine issues and a list of solutions. PWs need congestion control because they can carry any traffic, not congestion controlled, but continued health of Internet needs a congestion control of most traffic. Yakov Rekhter: PWs are not the only traffic with no CC. Look at multicast. Why does this have to be specific to PWs? Stewart : because we design PWs here Bruce: tunnel vision is not a PW problem, but PWs run over tunnels Reasons for not needing CC: If UDP, same as existing problem for UDP. Don't need this if it is TCP traffic. Don't want to add additional control to TCP. Overlapping control loops. Basic problem is that there is no mechanism to enforce congestion control. PW service only offered on well-engineered nets PW is a premium service that should be able to trample less important stuff. Never enough PW traffic to congest net on its own. Yakov: You are only solving a small part of the problem Mustapha Aissaoui: Congestion over the Internet exists, but what changes with PWs? Bruce: The difference is you give people new tools for congesting the Internet and a way of controlling it. Mustapha: But the end user mix of traffic doesn't change. Vach Kompella: what is this Internet? Isn't it a bunch of well-engineered nets? Bruce: turn off TCP CC then Vach: do congestion enforcement at the edges? What is the scope of this? Is it to protect PWs from each other, or Internet from PWs, or PWs from Internet? Yaakov: PWs are different from UDP. UDP starts at end users: PW at edge of network. Primary cases of concern: TDM PWs, Packet PWs carrying non-TCP traffic, deployed over widely shared infrastructure e.g. the Internet Not about protecting one PW from another. This is about protecting the network form a new type of traffic. Design constraints: large numbers of PWs per edge device so TCP-like state per PW too costly, hardware data plane already implemented etc Draft talks about a number of trade offs. How to detect/measure loss rate / congestion? Sequence numbers or OAM, how to feed loss rate back to sender, what to do on congestion, what to do as congestion abates, granularity of tunnel. Detecting congestions: sequence numbers could give false signals if reordering occurs, control / management plane, ... feedback egress to ingress TCP friendly rate control from RFC3448. Could police/shape PW to that rate. Similar to FC approach. Exactly what is the right way to measure congestion and set rate? How often to sample loss? How to enforce rate? Should this be mandatory for all PWs? Yakov Rekhter: There is only one issue. How to get some sanity into IESG?! Secondly, how to enforce rate. You have a router with 2 PWs. Shut down one, and all traffic from this is moved to 2nd PW. This gives you no option. Bruce: this is discussed in the draft. Danny: please read draft and provide comments. Lars: Want to make it clear that for vast majority of deployments this s not needed. Fear is that some implementation causes a problem at the edges. Needs to be something that prevents high data rate traffic ?: if a Linux implementer does Ethernet over IP, he can choose not to implement this and mess up internet. Lars: better to give a mechanism and then it might be implemented Sasha: mandatory to implement and option not to enable, doesn't help much. Lars: hopefully would have a guideline document in these conditions. Mostly for TDM PWs, and for packet PWs when we don't know they carry TCP friendly traffic. ?: why is there a problem if there is an SLA? Bruce: may not be an SLA Dynamic Placement of Pseudowires using a Path Computation Element - Luca Martini (lmartini@cisco.com) ---------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-martini-pwe3-ms-pw-pce-01.txt Cannot guarantee a best path between multiple ASs for MS-PWs using BGP. OK for a simple network, but can end up with a much more complex network. Here PCE becomes useful. Shows a walk through of a complex example. Recursive computation of paths through multiple service providers PE/P routers do not need info, so flooding in IGP not the nest solution. Can send this information directly to the PCE. Shows constraints that we should use: bandwidth, delay, diversity. There is an assumption that the PSN has more BW : PSN can resize the tunnel. PCE supports this. Needs some help from the WG in progressing this Yaakov Stein: still not sure what work you are asking for. Algorithm for best path? No. Extend PCE protocols for PCE-SPE link? No we have this. Luca: Need to extend PCEP protocol to use MS-PW address family. Yaakov: is this too early? Luca: no. Have updated segmented PW draft for Ben Niven-Jenkins: in a MH-PW system have a general problem, and one solution is PCE. Not clear if problem is well understood by the WG. Message Mapping Draft Status - Luca Martini (lmartini@cisco.com) ---------------------------------------------------------------- http://www.ietf.org/internet-drafts/ Message mapping draft seems to have a couple of issues. Doesn't talk about Ethernet OAM or LMI. Also contradicts RFC 4447 that needs to be addressed. RFC4447 Says if you are using PW status should not use BFD status. ADs said must have a common denominator with other options. Tom Nadeau: it is consistent in VCCV, so all we need to do is put it back. Yaakov Stein: if we put it into VCCV, why is it mandatory in the PW status Luca: meant VCCV the draft, not the protocol. Mustapha Aissaoui: for static PWs use BFD. Just need to clarify this. Ethernet OAM, we agreed to progress draft as it is not, because in order to add Ethernet will take another 2 years. Luca: can develop a more general interface. Mustapha: can cause a problem for a developer. Danny: discussion on the list. Multihop VCCV - Mustapha Aissaoui (mustapha.aissaoui@alcatel.com) & Tom Nadeau (tdnadeau@cisco.com) --------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-hart-pwe3-segmented-pw-vccv-01.txt http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-pw-04.txt Presentation at last IETF on proposal. Another proposal in the segmented draft. Mustapha discussed with Tom and Luca. Requirements were that a switching point is required to continue to operate VCCV end to end. 2 methods for this. Both methods required based on what has been deployed. Initial text in segmented PW draft. Will be published shortly. Both methods do end to end VCCV, partial tracing from T-PE and between S-PEs, and an automated trace function. Shows how this is signalled. New VCCV type. New channel type for MH-VCCV CW. Next steps: add details of control plane processing. Don O'Connor: can you also do this in BFD? Mustapha: yes Don: can you make a separate MH-VCCV draft? Mustapha: if people think this is straight forward can just put in segmented PW draft Don: should be in a separate draft, and should be extended to multi-provider networks. Stewart: agree that we should extend it to this case. Tom: already discussed this, but do not agree it needs a new document. Application of PWE3 to MPLS Transport Networks - Stewart Bryant (stbryant@cisco.com) ------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-bryant-pwe3-mpls-transport-00.txt Background: ITU-SG15 has been working on a design for MPLS server layer for use in a construction of a transport network. T-MPLS has been described in various ITU meetings as a subset or an extended subset of MPLS+PWE3 T-MPLS was liaised to IETF rather late in process, when it was too late to change. After 2 meetings and much discussion between IESG members and ITU there are still concerns. Not clear whether T-MPLS is a subset of Ethernet PW over MPLS, or an "extended subset". Problem is that T-MPLS uses the same Ethertype, and if not compatible could be problematic. Prior to IETF involvement there was no requirements doc - now there is. T-MPLS uses same Ethertypes as MPLS, so cannot be distinguished on the wire. Key requirements from ITU include: - no merging - no PHP in network layer - bi directional/unidirectional pt-pt with reciprocal paths - ability to operate without IP in the network - etc. Shows an architecture diagram layering IP/MPLS LSP on top of Ethernet PW on T- MPLS tunnel Shows how PWE3 would support this Suggests should use VCCV for OAM, with or without IP headers. External MPLS configuration or a profile applies when RSVP-TE used. Next steps: please read drafts and the liaisons. Need to consider what to do next. Need to protect investment and authority to design this. Andy Malis: too early to talk about a WG item because it is out of charter. This will lead to multiple ways of doing the same thing. Would rather see us work closer with the ITU. Don O'Connor: protection switching is needed to do this. Vach Kompella: vote to liaise this to the ITU. This doesn't line up with what the ITU solution is, apart from the requirements. Stewart: need to figure out how to not end up with 2 incompatible implementations Ben: why is it mandatory not to use sequence numbers? Stewart: Just copied requirements Dimitri Papadimitriou: does it cover MS-PW? Stewart: yes Dimitri: is the MPLS part of the PWE3 working group? Are we covering PWE3 part here, and MPLS part elsewhere? Stewart: we do transport of Ethernet wires over MPLS PSN, and that is their description Dimitri: need to engage with ITU folks as soon as possible to have right starting point Gert Grammel: We had a discussion in CCAMP where tried to understand requirements from ITU. Would it not be better to cut draft into 2 to understand requirement, and propose solution in a separate draft. Monique Morrow: need to do two things. We have been doing liaison statements. I would propose that we do 2. Dave Allan: PWE3 isn't really the right place to do this. The intention of the ITU is to move beyond pt-pt transport. Best thing juts to liaise this back. Mustaha: vote for 4 to demonstrate we have understood the requirements. Yakov Rekhter: strongly support 4 to show that we can do what T-MPLS wants today. But encourage the authors to continue to work on this as it is a good starting point. Y.1731 format for VCCV - Yaakov Stein (yaakov_s@rad.com) -------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-mohan-pwe3-vccv-eth-00.txt No covered due to lack of time. MEETING CLOSES