PWE3 - Thursday, November 12, 2009 13:00 - 15:00 (See below for WEBEX info) ------------------------------------------------ CHAIRS: Stewart Bryant and Matthew Bocci Secretary: David Sinicrope 15 min - WG Adgenda and Status - Stewart Bryant and Matthew Bocci See slides: For the no PHP draft waiting for Lou and George to resolve Lou's comment IESG CepMib - need to chase authors to compmlete it. Segmented PW - Significant discusses - need several days of work to resolve. Luca will resolve after Hiroshima in the next month or so. OAM Msg Map - Need a revised ID - editors and authers of OAM drafts will work with chairs to formaulate a plan to complete P2mp reqs - is this ready for last call? in pretty good shape for last call. Need to address reference model and clarify some minor points and it should be ready for last call. poll for WG drafts - static status draft refrences mpls-tp, the mpls-tp should determine applicability to MPLS-TP. Remove MPLS-TP references to make it a PW draft and let MPLS determine applicability and reference it. Would like to decision by 22nd. MPLS-TP and PWE3 Discussed during meeting, authors of framework draft will clarify Friday. No questions or comments. 10 min - P2MP PW Accounting Extensions - Bo Wu http://tools.ietf.org/id/draft-wu-pwe3-p2mp-pw-accounting-extensions-00.txt Wu presented, see slides Questions: Fred: not against method to communicate from leaf to root PE, need the information. Dave Allan: clarification - motivation for collecting stats for a management system for a part of the network the mgmt system is not responsible for. Fred: need info from leaf to root, to ensure that traffic going to CE. Dave: really want to verify the leaf supplier is actually doing what they said they were doing. Luca: Issues with proposal, requirement is valid. Historically we havne't put net mgmt information in the routing or control protocol. Need to ensure doesn't have adverse affect. The WG dealing with Net Mgmt should be asked how to address the problem, doesn't belong here or in control plane. Needs to be solved by the approporiate protocol. xxxx: use VCCV? Luca: VCCV is a test tool, not for this use Sasha: perhaps ANCP or another workgroup may be a better place for this. Matthew: (as ANCP Chair) worth looking at this to see if it fits with ANCP. No further comments. 10 min - Pseudowire (PW) Redundancy - Matthew Bocci for Praveen Muley http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-02.txt http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-02.txt See slides: Matthew presented for Praveen Brief update on PW redundancy Updates from V1 Next step requesting WG last call for both documents Comments: none 10 min - Flow Aware Transport of Pseudowires over an MPLS PSN - Stewart Bryant http://tools.ietf.org/html/draft-ietf-pwe3-fat-pw-02 Stewart presented, see slides Changes from 00 to 01 Changes from 01 to 02 - changes to signaling to avoid lock up clarified MSPW case Both Sides FL Capable One Side Capable case where one side doesn't know how to do this left side assigns FL, then when sees right can't it withdraws FL WG Draft - requests for minor clarification in signaling and marking bits to reserved. Will be corrected and will issue a new version in coming weeks and request WG last call. Questions: Fred: reason we are wokring on FAT PW - will you add a section for MS PW? could be used for P2MP too? Do you intend to clarify the text? Stewart: haven't going through P2PMP case, could put it in there but P2MP is not ready really. Will talk to Fred offline, but would like to keep this p2p for now. No other comments 10 min - Packet Pseudowire Encapsulation over an MPLS PSN - Stewart Bryant http://tools.ietf.org/id/draft-bryant-pwe3-packet-pw-02.txt See Stewart's slides. Pkt PW Forwarding Model - Useful describing internal structure in draft, highlight there is a PW component followed by LSR component. PID Label - For most client networks, there is a suite of protocols that run between routers, not just one protocol. Label Stack - PLDP PID Fec Element - can't signal PID on interface parameters so created a new FEC and then signal the binding between the protocol type and label to indicate protocol type. A PE could use a global label for doing this so when running e.g., IP it would always come in on the same label. Would like to make a WG draft Questions: Albert: Label Stack - is PID label just a regular label? Must use cplane to bind label to protocol label Could you globally assign protocol type to the label. Stewart: global labels have been proposed often and been dismissed each time Albert: will bring a draft to propose them Stewart: you are free to do so, but it stands little chance of acceptance Albert: Yakov suggested to look at previous global label discussions, but couldn't find any so no reason to stop pursuing global labels Fred: why did you go with FEC? Stewart: could do with interface parameters, but if you add a new type you have to take down and bring PW back up, not desirable Fred: could propose signaling just for Stewart: will take after list. Sasha: Never defined a GRE PW, but if we did wouldn't it solve all problems? Stewart: this is better fit for MPLS forwarding engine. GRE requires more Sasha: Not sure if label provide perf benefits, but if you use GRE you don't need new signaling. You don't need to do anything to add protocols. Take to list Malcolm: How do you plan to keep this aligned with MPLS-TP and keep ITU-T informed Stewart: This is PWE3 work and if MPLS-TP would like to use this then they can make that decision. Malcolm: Don't like that answer Stewart: This is purely a PW draft not dedicated to MPLS-TP Italo: looking at packet format how would OAM work in an ECMP based network OAM would not fate share with data. Stewart: where that's not good enough you use flow label. Italo: flow label associates traffic together, but doesn't keep traffic on same path in the intermediate nodes. Could take offline, need to look at OAM. No further comments. Concensus call on making WG draft: need more folks to read the draft. 10 min - Control Word Reserved bit for use in E-Tree - Fred Jounay for Simon Delord http://tools.ietf.org/id/draft-delord-pwe3-cw-bit-etree-00.txt Fred Jounay presented Investigating the way to provide E-Tree over VPN particularly with VPLS. Etree - VPLS for Etree- Problem - A Simple Fix - use one bit to distinguish root or leaf traffic RFC 4448 - Eth ove rMPLS control word Extension to RFC 4448 - use the L bit, bit 4 1:leaf, 0:root Control word Lbit - Questions: Florin Balus: Need a solution to address more than just VPLS, that uses the Ethernet header. A number of ways to handle this. Try in IEEE. If no interest do here in IETF. Fred: There are many cases not just PBB. This is a straight forward solution for VPLS. Florin: good idea to run by IEEE. Dave: could use source sink attributes on the ISID. If large number of leafs then will have a large amount of flooded multicast traffic because filtered after multicast. Are you trying to use one mesh in different contexts. Can take offline. Luca: Similar comment can, take a VPLS with BGP discovery and can achieve this today. This may have advantages because less PWs. Need more discussion before modifying forward plane. No further comments. 10 min - Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP - Luca Martini http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01.txt (Note: (results of merging draft-martini-pwe3-p2mp-pw-00 and draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03 ) Luca presented slides Many authors Changes for original documents - Open Issues Only reason we haven't declared WG document is because we agreed to hold until Nov 22, but hard to believe it won't be accepted. Comments: Loa: in MPLS WG we were tasked to do some IANA registrations. There are a number of temporary allocations that have expired. Luca: those are related to the Segmented PW document. It is in IESG review so there is little risk of them being reallocated. Stewart: work took longer than expected, so exceeded 1yr+1yr deadline. They are being used. Loa: talk to IANA and get them extended temporarily for next 3-4 months Stewart: Possibly get help from Ralph since outside early allocation window Loa: starting to allocate new codes out of same space so in jeopardy of colliding George: A year or so ago drafts were expiring in IESG review. Got that changed, so should try to do this for this as well. Loa: agree Stewart: I will write to IANA and CC Ralph so that Ralph will endorse. George: CC Russ as well attempt to change policy. No further comments. - Multiple MIPs and MEPs discussion will do tomorrow. 5 min - Closing - Stewart Bryant and Matthew Bocci PWE3 - Friday, November 13, 2009 9:00 - 11:30 (MPLS-TP - joint with MPLS WG) --------------------------------------------- (See below for WEBEX info) CHAIRS: Stewart Bryant and Matthew Bocci Secretary: David Sinicrope 10 min - LDP Extensions for MPLS-TP PW OAM configuration - Fei Zhang http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-00 See slides, Fei presented. Questions Sasha: What happens to BFD discriminators in non-MPLS-TP case? Don't believe they are signaled in anyway. If dont' need to signal in that situation, then why in MPLS-TP situation? Fei: They are signaled in RSVP Attila: good idea to look at configuration. Will be interesting to see what OAM objects would be signaled Albert: do you mean you would prefer this proposal? Attila: No, some functions currently in MPLS OAM that solve these issues. good to have some discussion in document of parameters and use cases. Albert: how do you think RSVP-TE autoconfig is related. Attila: it looks like the same but should be clarified. No further comments. MPLS-TP drafts not covered in the last MPLS session that weren't on the PWE3 agenda: 10 min - Diagnostic tool-test for MPLS transport profile - Feng Huang/Lieven Leverau http://tools.ietf.org/html/draft-flh-mpls-tp-oam-diagnostic-test-00 See slides, Feng presented What's diagnostic tools? - Out of service test - In service test - needs discussion TST frame suggestion - Next Steps - Questions: no questions 10 min - MPLS-TP Lock Instruction - Xue Hui Dai http://tools.ietf.org/html/draft-dai-mpls-tp-lock-instruct-00 See slides, Dai presented Background - Example: - node A sends lock requests periodically to node B and propogates to C and D, and each creates a lock response and sends through opposite direction. A sends the requests until it receives a response from each node in the path. Message Format - Next Steps - Questions: Lou Berger: Are the MEPS and MIPS PW or LSP? Dai: both Lou: interesting mixing of layers raising some procedural questions. Common requirements and solutions across working groups. How do we manage this? On prev talk we see things coord w/ CCAMP, on this one PWE3 and MPLS. Don't know how we talk about procedural point. Stewart: This is the MPLS overflow part of the agenda so this is MPLS work Lou: comment still holds, but applies to MPLS Chairs, but needs to be discussed, but not technical point. Loa Andersson: How we proceed... you met with Sami Boutros and agreed to merge two drafts into one draft. Dai: yes Luca Martini: requires more discussion. Not sure you can lock one direction of a PW. Depends on what you mean by Lock. In a PW if one side fails to transmit, the other direction is taken down. Would be nice to make a distinction of the lock level, PW or LSP level... two types of locks. Can't figure out if there is a way to determine lock type. Stewart: why do you need indication Luca: Only one ACH in the draft. Stewart: if sent on PW applies to PW, if on LSP applies to LSP Dai: yes Kam Lam: depends on which MEP you apply instruction, if on PW, then PW, if LSP then LSP Sasha: Draft applies to not just PW and LSPs, but also for sections right? Dai: Yes Sasha: if locking sections in traditional transport networks, does that exist in traditional transport networks? Lou: what we have other than PW and LSP? Sasha: we have sections Lou: we have PW and LSP labels there is nothing else. Not sure what you mean if not PW or LSP labels. Sasha: draft says can be applied to LSPs, PWs and sections - MPLS-TP allows notion of sections. Is it necessary to apply lock to MPLS-TP sections? Wu Bo: in this draft it focuses on LSP and PW. Requirements of sections need to be discussed. No further comments. 10 min - Multiprotocol Label Switching Transport NM Auto discovery requirement - Qiaogang Chen http://tools.ietf.org/html/draft-chen-mpls-tp-nm-discovery-req-00 See slides What is it - Example - Problems - Problems facing NMS - Topology Management function - Motive for discovery - Discovery for SDH and WDM ... Next Steps - accept as WG document Questions: Stewart - is this similar to the discussion in Q14 at the last ITU-T meeting Kam: suggestion then was to bring to mail list and bring internet draft. There was mail list discussions and this is the resulting draft. Stewart: this is to collect information for the NMS so the NMS understands the topology ???: don't see need for special discovery when we have the MIBs Stewart: issue is how the mibs get the information to begin with. Need to find out who is attached so you can put it in the mib. Note noone signed up to do MIB work Scott: if accepted it would need to go to MPLS-TP NM framework document, but need separate draft because of state of where the NM requirements document. No one assigned to do MIBs yet. Loa: need to settle framework first then discussion on how discovery works in a TP network and what the delta. First need to decide what additions there are to the MIBs. Need to think about requirement and framework than then settle on motivation Stewart: Need a mech to discover information available in adjacencies then figure where it goes in the mib. What we want to discover, how to get it into the MIB and then a mech for getting the info from your adjacencies. 3 problems that can be addressed in parallel. Loa: Not clear here. Why do you need to ask the neighbors if NMS does that? Stewart: In ITU-T discussion problem is to discover who neighbors are because unknown or wrong. Need CDP or Kam: if NMS has capacity of getting realtime data then no problem to solve. But motivation is that we need a mechanism to help NMS. Adrian: subtle difference between cross checking or verification and discovery. There are protocols already for discovery in LMP Stewart: agrees with Adrian Kam: Need to take into consideration the difference of the two different issues. No further comments. 10 min - SD-Triggered Protection Switching in MPLS-TP- Huub van Helvoort http://tools.ietf.org/html/draft-zhl-mpls-tp-sd-01 Huub van Helvoort presented. See slides Requirements - Motivation - Flapping example - SD triggered protection - SD-Triggered protection - SD-Triggered Prot - broadcast bridge Next Steps - Questions: Loa: asked to Yqacov on Wed, he discussed a weak signal and you discuss signal degrade, think they are similar and have good idea on physical media, but here we have packets. Have you done any work on defining signal degrade on packets networks? Is it additional delay? Loss? Huub: determined on delay and loss measurement and thresholds Loa: Would like to have much more clarified than what is here. Like to have another term than signal degrade to distinguish it from physical layer. Huub: could use Service Degrade w/ same acronym Albert: This draft is high level procedure draft, no protocol? Huub: this is just high level priority setting, just an additional priority in list. Stewart: then why does it need a draft in its own right except to define "service degrade", but is just a note to each of the protection switching teams to account for this in other drafts. Huub: Yes Stewart: but doesn't need to be a WG draft to do this Huub: right, just want principle accepted Stewart: then just need defintion and a paragraph to each other authors Huub: right. No further comments. - remaining time will be used to continue OAM discussions from earlier in the week. Stewart: 2 topics to discuss 1 - client discussion and 2 MIP and MEP discussions Any other work to do before we close formal session and go into a work shop mode. Client Discussion ----------------- Matthew presented slide on clients of MPLS-TP and relationships. removed 2nd PW case removed because handled by the remaining cases - middle case is a labeled service - position of Sbit depends on what is being carried - main conclusion that in a PW case it may use a NULL label Questions: Loa: do you mean an explicit NULL label from the reserved space or doesn't need to be there Stewart: doesn't need to be there in the case in two pes adjacent Loa: use another word than NULL Matthew: OK Stewart: could just say it is PHP for the * note Albert: MPLS-TP will set Sbit to 1 if IP as payload so must know what payload to determine S bit and differentiate cases. Matthew: must know whether labeled service or IP Albert: this is not unified model, in case 1 sbit is 1, 2nd sbit 0, third sbit -1 Matthew: not unified but best we have today Albert: could have two Sbits set to 1 to distinguish layers Loa: sticking to Sbits in same label stack is major architectural change, MPLS-TP does not make MPLS architecture changes Luca: In middle stack, the way its set up now is understood. comes in port and goes out another port. Not compelling case. Compelling case is to come in one port and go to many, in which case the label is not NULL or missing Lou: going back to NULL label case, in middle column, In that case where is the Sbit set? in the PW label Dave Allan: The middle column can be broken into 3 cases - Sbit =1 in the IP case Stewart: is same as right case Dave: In left scenario can have more than one... 1) S=1 in the TP label space, PHP'd IP/MPLS (which was a special case of the RHS due to control plane implications) 2) S=1 in an IP/MPLS label, client would be IP 3) S=0 in any IP/MPLS label, client was S=1 in a PW label Lou: what represented here is what is different in the framework and reflects agreements from this week. Stewart: will update framework document to include this section and will send section for comment Matthew: this hasn't yet been uploaded Stewart: any other comment so we can write this up and not revisit at each meeting Adrian: more to likely. Suggest 2nd picture to indicate control word so people understand where control work fits. Stewart: TP PWs always use control word, Others are optional Martin: In follwoign with what Adrian said, it would make sense to have a picture with a GAL Stewart: need a lot more text on framework on this. Matthew: we can break this into more detail. Stewart: Lou, still expecting more text on NLTS? this is a section explaining layering. Do you need to provide more text? Lou: let's see what it looks like after you write the section. Italo Busi: This clarifies one of my comments on the draft about positioning Sbit. Still need to clarify the LSP when carrying LSP. Matthew: you mean what processing applies to what labels on the stack. Raises one question on NLTS, may need more text. Lou: same as previous discussion, depends on how it is written. Stewart: we know what the PW internal structure looks like, but not LSR Lou: LSR material already exists. We should reuse and see what is missing. First step is to take first pass. Enrique: if it is a Pkt PW, can you add clarification of where the client layer is set? Stewart: if PW is provided by TP service then left side, if provided by TP network then middle. substitute PW label for PW package of labels Matthew: but where does it sit relative to the client line? Different depending on protocol of payload. Stewart: In left column with current def of packet PW, then S=1 label is the PID label and all is shuffled down one. There is a boundary between client and Server and even if in same equipment, boundary still exists. Andy Malis: intended deployment case is the left column. Packets between routers in the item marked PW payload Stewart: right, and there may well be vpn labels in there as well. Lou: that's how use would use it or you care more about far left than far right. Andy: I care more about far left than right. 1st application will be router interconnect over transport network. Lou: you can use far left if PW, but if router interconnect is IP based can use center or right. Andy: but in that case would use center or right, more apt to use as client interconnect e.g., carrier of carriers Lou: if router to router would use just IP? Andy: no routers need to carry more than IP, e.g., routing protocols and MPLS Lou: far right can do that, IP is just an exampmle Andy: far right can't do CNLP Lou: would just be another PID Andy: no, currently defined clients for MPLS are IP, PW and MPLS. Lou: what can you carry in an MPLS labeled tunnel other than a PW? Doc says anything that has a network layer value. Andy: that's what section 7 has in the TP framework Lou: also in 3031 Andy: need to check Loa:says network layer protocol, one of the requirements when we started WG. Stewart: wouldn't want to change the arch Lou: RSVP-TE has a PID, so anything that fits in the PID would be valid Stewart: will incorporate the text with the authors of the framework along with this discussion and send it out. Lou: we aren't changing the architecture and we are going to do what MPLS allows for Stewart: we all agree on this point Italo: yes but we have different ideas on what this means Lou: look at 3031 and RSVP-TE (and 3032) Stewart: for general label service this is how we would carry MPLS-TP over MPLS-TP when provided by two different service providers. No further comments. End of topic MIPS and MEPS Discussion ------------------------ Luca presenting Trying to address question where one MIP in the middle and a MEP on either side. Folks want one MIP and 2 MEPS in the middle Need to deliver packet to SN2 - can address both MIPS without changing architecture using TTL. This is for soft loop, eg.,LSP ping message to either of the MIPS For hard loop, we can use address of the MIPs per the identifiers draft. Dave Allan: discussing a separate means of steering things in the box when TTL is expired, which has nothing to do with forwarding and not fate shared with data. Luca: it is implementation specific Dave: but it is not fate shared with how labels are forwarded. Luca: could do this in exactly the same way as forwarding data Dave: skeptical Stewart: alternative proposal? Dave: no Stewart: so this is the best we have to date Dave: this adds a lot of complexity that doens't accomplish anything Loa: if I loop to 2 and get response and loop to 3 and don't what conclusion? Luca: would need to do further investigation to see where break in the box, or implementation would send an alarm. This maintains what providers use today ???: Clarification that this solution is TTL0 and egress MIP Luca: difficult to say what is inside the box Adrian: channeling for Nurit - will this go in channel or data plan Luca: data plane, unless switch with no central processing, implementaiton specific Loa: req that Nurit presneted should be able to monitor LSP end-end, the requirement to put a MIP here and there is close to specifying a solution. This requirement is in the spec already. No problem with requirement, but not specific solution. Lou: What's the requirement? Don't remember requirements that state nearend vs. far end loop. If we have those requirements we have many functions to do this, but don't know where to support, near or far end. Sasha: What actually is lifespan of the MIP. If it is on a port and shares its fate with the port, then when the port goes down, then MIP3 will stop to exist and not respond and then this scheme can't differentiate between the failure of SN3 and link. IETF doesn't deal with line cards. So long as req mentions that there may be one MIP per network element or more than one, then it should mention what their lifespans are. Stewart: OAM framework should add as clarification Sasha: yes and OAM reqs docuemnt should clarify what it means to have more than one MIP. Loa: its in there Luca: Not attached to up or down of port. If port exists then it exists as well. Don't need to point to line cards. Sasha: should be driven in more detail Martin: mixing OAM framework and OAM requirements document Italo: issue with req vs. implementation - for OAM framework we are investigating and will reflect Sasha's comments. All that needs to be specified is more than one mip/node is allowed and how to access them. How this is done is implementation issue. Kam: whether 1 or 2 mips / node is in context of LSP. Another LSP may be different. Luca: yes Yoshinori: checking of switching can be done in another way. Loa: There are different discussions going 1. The requirements cover what we need to do this work. No need to change the requirement spec. 2. A MIP or MEP instance is per LSP. May be trying to say something else. Luca: there is a MIP per port per LSP. Stewart: a MIP is a point somewhere on an LSP. Proposal here is that you can have a finer granulary somewhere on node and can say its at ingress and egress. Loa: yes port is the term that's an issue. Kam: solves problem with lifespan of MIP, goes with LSP and whether you want OAM at a node. Yoshinori:before we discuss a function we need to make clear where measurement or test should be done. Important from maintanence perspective. Need to be clear where maintanence points are. One point somewhere is not so clear need to be clear where maintenance is done. Loa: not clear whether you want to add new work in the framework or add requirements to the MPLS-TP requirements. Yoshinori: discussing OAM framework and already discusses 2 mips Loa: want clear statement don't need to change OAM Requirement spec. This came up after IETF last call and want to ensure it is resolved. Yoshinori: just want to include in OAM Framework, no change to OAM requreiments is needed. Kam: OAM requirement states at high level, lower level detail can be done in framework Manuel Paul: important to have framework a more detailed description of requirements so we can ensure data and forwarding plane doing what is expected. ???: Luca: Does not include performance monitoring Albert: in a traditional IP network we only use on IP address and one MIP, you only need to know whether it is reachable, LSP different. Need detailed approach along the nodes. 2 MIPS in one node only one case for P2MP may be different. On maintenance pont in one node but have sub-objects to make it more flexible, rather than have multiple MIPs. Luca: you can have as many objects as you wnat and packet will do same thing Stewart: is point that in P2MP you need more than one port? Could use more than one bit for this. Albert: for one ingress multiple egress how do you do? Luca: can select one of the multiple egresses Stewart: do you mean line card ingress, line card egress etc. Albert: internal points in the box Luca: maybe we should represent as on MIP with sub MIPS, whatever is clearer to the reader Albert: unified model is clearer, but don't have a proposal Stewart: we only really specify external behavior Luca: yes but we could say in MIP with ingress and egress sub MIPs Stewart: or multipls with different identification Yoshinori: regarding my draft I would like to reinforce the reason and make it clearer why ingress and egress MIP is needed. Italo: focusing here on pt to pt case. in the p2mp case we would have a different scenario and issues to be added to the framework document. could use a bit to indicate that all egresses should respond or one particular, but needs more discussion. Lou: interesting thing there is that you can use one bit in dataplane and get all addressing cases. Luca: still need to have a p2mp lsp in MPLS-TP, not described yet Lou: general discussion on what is really addressing. Do we have addressing for control function or for dataplane function. If we need addressing in dataplane layer, then somewhere w/ hardware you can pass thorugh the input interface. Doing this with the smallest hardware change is useful. Assuming 2 mips from forwarding standpoint then translates to forwarding changes. If only loop on a connection can use existing TTL with addressing, but depends on requirements. Looks like we are going with datapath, 8 bit solution not sure will fly. Luca: need a simpler addressing than full identifier Lou: key is how to bypass. No further comments. FORMAL SESSION CLOSED Document authors: Any authors to use the remaining 7 minutes... Italo:couple of outstanding issues in the OAM framework draft 1. appending the PW to the scope of the discussion as a client - framework will discuss PWs now. PWs are part of the solution, so where special things needed better be documented. 2. PW arch of MEPS and MIPS are SPE MIPS and MEPS - do MIPS exist in MSPWs, because maint entity have some characteristics of MIPS and MEPS because control plane function changes on each interfaces. Some OAM funciton must handle case where function changes. The stitching of MEPS and MIPS doesn't change with the stitching of dynamic to static PW Characterize the MEP and MIP in OAM Framework and map onto what is done in PW. 3. Tandem connection monitoring of PW. What is issue?? the key point is I have a MSPW I want to monitor between 2 points. The only thing I can do is set up an LSP between the 2 points put the PW in this LSP and monitor the LSP. Italo wants to do TCM in the PW layer, which needs to be investigated. END OF SESSION ********************************************************************** WEBEX INFORMATION FOR THE PWE3 SESSION - THURSDAY ********************************************************************** IETF Secretariat invites you to attend this online meeting. Topic: pwe3 at IETF 76 Date: Thursday, November 12, 2009 Time: 12:45 pm, Japan Time (Tokyo, GMT+09:00) Meeting Number: 964 069 917 Meeting Password: pwe3 ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=130168712&UID=0&PW=NZTFjZTNiMjdi&RT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: pwe3 4. Click "Join Now". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=130168712&UID=0&PW=NZTFjZTNiMjdi&ORT=MiM0OQ%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:964 069 917 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris at amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=130168712&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=pnOOWUWJ53rgcA1ANMeNJjtXK9up0xXaq21P0ipfRUg=&RT=MiM0OQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com ********************************************************************** WEBEX INFORMATION FOR THE PWE3 SESSION - FRIDAY ********************************************************************** IETF Secretariat invites you to attend this online meeting. Topic: pwe3 at IETF 76 Date: Friday, November 13, 2009 Time: 8:45 am, Japan Time (Tokyo, GMT+09:00) Meeting Number: 964 750 155 Meeting Password: pwe3 ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=130207752&UID=0&PW=NNzhiYTFlNjUw&RT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: pwe3 4. Click "Join Now". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=130207752&UID=0&PW=NNzhiYTFlNjUw&ORT=MiM0OQ%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:964 750 155 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=130207752&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=duHnJdh5mXqv2Om2R/qR1s314y-oL7/yC-GU2d5Xho0=&RT=MiM0OQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session.