Agenda bash chairs, 5 min agenda agreed WG Status chairs, 20 min one new rfc (rfc5654), 5 drafts in RFC editor queue Loa said few words on the MEAD (MPLS Interoperability Design Team) lot of good work achieved but perceptions creation of a "steering group" that will meet regularly 4 drafts in IESG processing Adrian: LC just ended MPLS-TP mode of work: working groups involved: mpls (lead), pwe3, ccamp, l2vpn, opsawg consensus list is mpls-tp@ietf.org Loa presented the MPLS-TP OAM drafts status following Stockholm meeting draft-ietf-mpls-ldp-p2mp-08 - 5min - Ice Presented changes from 07 version Waiting (Chairs') support for early IANA allocation and would like to move to WG LC. Loa: about the early IANA registration First time I would do this, so would need support from ADs and involvement from PWE3 chairs. draft-wijnands-mpls-mldp-csc-01 - 5min - Ice This drafts was also presented in L3VPN (section that refers to L3VPNs) John Scudder: [missed question] draft-wijnands-mpls-in-band-signaling-02 - 5min - Ice Presented the changes based on comments received from Yakov Next steps: will limit RP discovery to static Would like to become WG draft Loa: how many have read the draft: only few hands, we will have to poll on the list draft-ietf-mpls-rsvp-te-no-php-oob-mapping-03 - 5min - George Updates: added flags in RRO for egress acknowledge OOB & PHP clarification of PID override default timeout selected (60s) Authors believe ready for WG LC Loa: do drafts depend on this? George: yes two Lou: what happens if RRO does not make it back? George: how could that happen? Lou: policy at given boundary Lou: does the mechanisms works without acknowledgement? George: [missed question] Thomas Morin: "MAY tear down the leaf". should not encourage tearing down leafs George: decouple RSVP from the application using it draft-bishnoi-mpls-mldp-opaque-types-01 - 5min - Sandeep Trying to address migration issues Luca: we now have 4 documents covering this in 3 different ways do we need one single document? Ice: this doc specific encoding for mLDP p2mp, mp2mp static configuration George: need to get to an alignment. Talk together please Thomas M.: Lack details to see how it fits in mVPN framework Drivers of the draft (security, provisioning) I am not convinced by the "provisioning". Security not convinced either. Ice: the driver if static mVPNs Loa: authors of 4 documents get together and see what needs to be aligned draft-bishnoi-mpls-ldp-node-group-00 - 5min - Sandeep Loa: how many have read? few hands Loa: please bring this to the list Luca: isn't it a routing protocol decision instead of an LDP's ? draft-ali-mpls-sig-pid-multiplexing-case-02 - 5min - Sami (Zafar) would like feedback and see adopted as wg document -no question- Loa: take this to WG list draft-chen-mpls-return-path-specified-lsp-ping-01 - 10min - Mach - no comment / no question - draft-chen-mpls-bfd-enhancement-00 - 10min - Mach Sasha: looks like mpls-tp work Sasha: could you explain why two bfd sessions operated independently fail to perform protection switching? Chen: because they operate independently Stewart: work should be done in bfd WG draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 - 10min - Kenji George: How many have read? a number of hands please bring this to the list draft-liu-mpls-rsvp-te-gr-frr-00 - 10mn - Autumn how many have read? a number of hands MPLS-TP process - 5min - Adrian Kam Lam: what is Historic? Adrian: remains in the archive but no utility Loa: I would not say "utility" there is useful Historic work Adrian: this is the point: still interest to read but directly not applicable Sasha: why not publish as BCP? Loa: the real message is that we have no intention to push this as an rfc before the end of the subject [missed name]: do you know how to access (without paying) ITU-T documents? Adrian: they are free [missed name]: what about pre-published? Adrian: those that relate to tp should be liaised to us Julien: does the itu-t commits to a process on its side? Adrian: ITU-T has specific rules for modifying their process. draft-ietf-mpls-tp-nm-framework-01 - 5mn - Scott - no comment / no question - draft-ietf-mpls-tp-oam-framework-02 - 10min - Italo Dave joined, Italo presented the changes from 01 to 02 Malcolm: would like the two frameworks consistent on p2mp oam framework covers both and we have two separate docs for the general fwk Loa: I understand but do not see why necessary Nurit: [missed question] Dave: Support Malcolm, oam framework will have to cover p2mp but should not do so in advance of general p2mp framework Stewart: so we put p2mp back in general framework or keep current plan? Loa: keep with plans (separate) draft-ietf-mpls-tp-framework-06 - 10min - Matthew changes since last IETF: major rewrite to improve readability, expanded terminology removed the p2mp content, clarify scope of TP, arch clarifs (adaptation & forwarding Matthew presented, the mpls-tp scope, the mpls-tp clients services implemented using lsp: lsp, pw, ip services implemented by PWs: anything that is supported by a PW Lou: [missed question] Loa: this is work in progress, draft-sprecher-mpls-tp-oam-analysis-07 - 10min - Nurit Sasha: on Y.1731. is it correct to state that Y.1731 can be reused, e.g., 1731 uses mcast @ to reach points George: we said functionality, not mechanisms draft-asm-mpls-tp-bfd-cc-cv-01 - 10min - Annamaria Loa: on your next steps, will ask adoption after next rev? Annamaria: yes DaveW: the state machine does not change there might be a deadlock when session comes up and we are working on this but no change to state machine Yuji: I am confused on difference between BFD session and ME. Annamaria: please read, we have clarified. Yuji: Is session different from ME? Anna: no George: session happens between end points of ME. draft-nitinb-mpls-tp-lsp-ping-extensions-00 - 5min - Sami Loa: semantic question: Change 'MAY' to 'will': one identifier will be present Loa: we're out of time. draft-swallow-mpls-tp-identifiers-02 - 10min - George Sasha: on the means to identify operators Has ITU-T specified any ordering on operators identifiers J. Sadler: the draft currently does not specify any way for relocation of PWs and LSPs (i.e. in transport the end point does not always stay on same box) George: we have two types of IDs JS: ICC & other are global IDs, not what I talk about George: let's take this to the list draft-sfv-mpls-tp-fault-00 - 10min - George Would like it adapted as WG doc Dave A.: a server MEP sending to client MEP is layer violation George: I would be happy to have text Kam: different categories of fault described is 'transient' a fault? Lock is not of fault Would need to be clarify George: would be happy to clarify draft-frost-mpls-tp-loss-delay-00 - 10min - Dan Andrew L. why do we need multiple timestamp formats Stewart: [missed answer] George: to the list draft-sprecher-mpls-tp-survive-fwk-02 - 10min - Nurit - no comment / no question - draft-weingarten-mpls-tp-linear-protection-02 - 5min - Yaacov George: you seem to use opposite encodings for two similar contexts. Find this strange. Yaakov: I'll look at it. draft-weingarten-mpls-tp-ring-protection-01 - 10min - Yaacov presenting ongoing merge on Weingarten and Ceccarelli (p2mp ring) nest steps: develop applicability drafts, unify other ring drafts Italo: this describes linear mechanisms in ring topology but we have more optimized solutions and customers are very keen on this (e.g., G.8132) Nurit: no need for new solution unless your demonstrate bad performance Italo: N-square oam sessions George: please take this to the list Loa: how do you measure strength of signal? Yaacov: not really strength but whether we get signal from working or protect draft-umansky-mpls-tp-ring-protection-switching-00 - 10min - Huub Nurit: two ring in each directions. logical or physical rings? The document would need to incorporate more info on labels in details especially in the case of wrapping What is the relation between APS and PSC defined in linear draft and your draft Stewart: I would like to emphasize on the need to describe what label is pushed, popped, ... Stewart: what about node protection? Huub: on node, was not in the slides but is in the document draft-liu-mpls-tp-ring-protection-00 - 10min - Liu - no comment / no question - draft-jiang--mpls-tp-ring-fd-00 - 10min - Albert John overtime (21 slides in 10min) draft-koike-ietf-mpls-tp-oam-maintenance-points-00 - 10min - Yoshinori Luca: what happens if there is no fabric in the middle? this is linked to a system architecture Yoshinori: this is not linked to a particular implementation Luca: what happens if multiple fabrics in a box? Italo: look at the functional point of view: "entrance & exit of box" ingress & egress port draft-ietf-mpls-tp-rosetta-stone-01 - 5min - Huub huub gave an update George: on MEP. Draft says MEP = MEG End Point but other drafts say Maintenance End Point Huub: ITU says MEG End Point George: 1731 says Maintenance End Point draft-he-mpls-tp-csf-01 - 10min - Malcolm Merge with pw-status might be premature ************* the following happened during PWE3 Session on Friday ************* ****** see also http://tools.ietf.org/wg/pwe3/minutes?item=minutes76.html ****** 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... <**get Dave to clarify these cases**> 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.