1. Agenda bashing, WG status reports 17:40:0017:50:0010 Chairs 2 draft-ietf-teas-yang-te-topo 17:50:0018:00:0010 Xufeng Liu 3 draft-ietf-teas-yang-rsvp draft-ietf-teas-yang-te 18:00:0018:15:0015 Tarek Saad 4 draft-saad-mpls-static-yang 18:15:0018:15:000 Tarek Saad 5 draft-raza-mpls-ldp-mldp-yang 18:15:0018:30:0015 Rajiv Asati 6 draft-pkd-pce-pcep-yang 18:30:0018:40:0010 Dhruv Dhody 7 draft-zhang-ccamp-transport-ctrlnorth-yang 18:40:0018:50:0010 Xian Zhang 8 draft-zheng-mpls-lsp-ping-yang-cfg 18:50:0019:00:0010 Guangying Zheng 1 Agenda bashing, WG status reports10:00:0010:20:0020Chairs Meeting starting. Note well applies. A summary of WG status and activities. 2 ietf-mpls-rfc4379bis10:40:0010:50:0010Carlos + Kireeti Carlos presenting. [discussion] Kireeti Kompejja: question for the chairs - how are yyou targetting this document? Is it PS, is it DS? Loa: this is not a draft standard. My intention was to clean the document up, but when we discussed this further, we agreed that we would try to make it an internet standard. Kireeti: we should be careful on what we import that might have a different level of implementation maturity. We do not want to import something and then pull it out. Carlos: the principle that we used while this update is exactly that - what should we remove, and not what to overimport. Kireeti: many of the documents that we are importing have IANA registries. Do you plan to update those too? Loa: I would prefer to have everything in one place. But if it creates ambiguity, then we should leave it as it is. Kireeti: we are trying to reduce the confusion, not to create. Shahram Davari: you mentioned no interoperability issues - is that really the case? Carlos: we did not hear anything, if anyone knows anything please report. Loa: there is naother coordination direction that needs to be taken - LSP ping for multisegment PWs, need to align with what Sami is doing in PALS. Also it aplies to YANG models for LSP ping. Would encourage the authors to cooperate. Carlos: we will continue to edit the document incorporating the changes. And coordinating with other activities. 3draft-ietf-mpls-tp-shared-ring-protection10:50:0011:00:0010Liang Geng Liang presenting. [discussion] Robert Raszuk: this work overlaps with TE LFA work in SPRING. Why do we have parallel solutions as TE LFA works for rings. Liang: I am not aware when and by whom that problem was addressed? I will check and will bring it to the list. George Swallow: TE LFA does nothing about bandwidth reservations. Loa: we really need to bring technical changes to the document if those documents are WG documents to the mailing list, it is not only between the authors, you need to be really transparent when updating the documents. 4draft-ijln-mpls-rfc5036bis11:00:0011:15:0015Nic Leyman Nic prsenting. [discussion] Loa: last two bullets on IANA - discussed with IANA, they suggest to put a new section and in that section put a subsection of what is there verbatim in 5036, and then add another subsection to add anythign new. Loa: Also appendix is easy to do, just not intuitive - have discussed this with RFC editor. Loa: two important questions for me are what to do with FR and ATM. RF seems to be mostly gone. ATM we have got one voice that we should be carefull. That is something that we would like to get feedback on. Carlos Pignataro/Cisco: I think taking out FR is about time. If there is a pushback, put those two sections into a separate draft. 5draft-shen-mpls-egress-protection-framework11:15:0011:25:0010Jeffrey (Zhaohui) Zhang Jeffrey presenting. [discussion] Greg Mirsky/Ericsson: we had a good discussion about egress protection, and it is important to define what we call as ingress failure. We cannot reliably differentiate link and node failure. Jeffrey: this framework is for the egress node failure by manotiring the egress node liveness. This likely is not that complex problem, and we can continue on the mailing list. Raveendra Torvi via meetecho: [disconnected] Lucy Young/Huawei: there is already a solution work in TEAS for this problem. Why do we need another work here? Jeffrey: yes, there is work in TEAS. That is a particular solution that is specific to RSVP-TE. This framework tries to address all tunnel protocols and services in a generic way. Tjere has been many discussions with TEAS to align the work. There is another way to do this protection in RSVP-TE case without protocol extensions. Huaimo?/Huawei: you mentioned that you can provide egress protection without any protocol extensions. That is not true. Loa: I would like to step back a bit. Yes there are drafts in TEAS. This is a more high level document. This is along the lines of requirements - we wish to di it in some way, if it is not possible, then we do not do it. The TEAS document and this one are not contentious. Greg Mirsky/Ericsson: It is good to take a higher level look to the problem. Maybe two documents are needed - one will formulate the requirements, another propose the solution, Greg: I will repeat my question - what type of failure is considered? Does it include the concatenated link, or the one between .... Adrian: proxy for Yimin on jabber: TEAS draft is RSVP specific. Adrian: proxy for Yimin on jabber: this draft intends to provide an overvieww of the problem as well as a solution framework. 6draft-rosen-mpls-rfc3107bis11:25:0011:40:0015Ross Callon Ross presenting. [discussion] Lucy Young: In the IDR we have a new draft on FS for MPLS. That may also apply to this work. I see that this is possibly related here. Ross: we should take this offline and get Eric involved. Loa: Lucy should bring this to IDR WG and copy MPLS WG. Jorge Rabadan/Nokia: you mentioned this applies to VPN prefixes? Ross: 3107bis does not change or specify anything on VPN. Maybe say a similar approach is used for VPNs. Jorge: there should be some text to cover that. John Scudder: you mentioned on NLRI formatting that the format is not optimal. My comment is not to change that, just document the existing practices. If you do that it changes quite a lot, and this needs to be discussed in IDR, and for all address families. Keyur Patel/Cisco: I think the base document talks about the carruing multiple labels, and identifying the bottom is by the end of stack bit, but doies BGP need to know that? We should consider the ecoding that is faster on the wire. Ross: This all needs to be discussed on both lists George Swallow: if we change the parsing, itr needs to be in IDR. Jeff Tantsura: there are many discrepancies in implementations, we need to clarify the case of multiple rouites with same NH. We need to formalize it in strong language. Kireeti Kompella: two points: 1) if you plan to change this and capabilities is enough to differentiate, then let's do it in a right way. If you have a capability, you do not need to worry about breaking things. 2) If you have same prefix with different labels, that is a BGP thing, it should not be discussed here. Acee Lindem/Cisco: Have read the document and support it. With capabilities we can do what we want as that is a new behaviour - for multiple labels. Acee: For lucy;s comment - this is for documenting what is deploiyed, not the new functionality. Loa: who has read the document. Loa: those who have read the document, do you think that it is ready to become the wg document? George Swallow: if we add in the capability, we need to explicitely address that, What is in the draft will be hard to change later. This needs to be solved before adoption. George: that should be a hat off comment. 7draft-ietf-mpls-bfd-directed11:40:0011:50:0010Deborah Deborah presenting. [discussion] No questions or comments. 8draft-mtaillon-mpls-summary-frr-rsvpte11:50:0012:00:0010Tarek Saad Tarek presenting. [discussion] Lou Berger: you define a new mechanism for communication between transit LSRs, and that becomes a new way of doing a form of segment signalling. We have done that before in the context of segment recovery. Likely we did a wrong thing then and we should have defined a generic way of communication between midpoints, and when a new use case cames along, we should just reuse that. From the architecture standpoint, this seems to be abog deal. We need to think wehter we need to do a generic midpoint signalling. Tarek: ... Lou Berger: I am not saying that you move to segment protection. I suggest that you define a new midpoint signalling mechanism, and do it in a generic way. I am happy to think about it this week. Yes, this is something new, and you likely do not want to hear about it. Tarek: It is a mechanism to associate LSPs together. We find that this suits the requirement. 9draft-kompella-mpls-rmr12:00:0010:50:0010Kireeti Kompella Kireeti presenting. [discussion] Greg Mirsky/Ericsson: Regarding the format of flags - is SO a bitfield, or values? Kireeti: those all are bit fields for small values. Yes, it is a bit field. The OAM mechanism that you pick will be indicated as a bitmask for capabilities, and as a number for links. Greg: having MBZ bits is good, as we might have new OAM mechanisms. Greg: when you are signalling the resulting protocol, we will need more bits to represent more supportted protocols. Kireeti: do you sugegst expanding the bitfields now? 10draft-turaga-mpls-test-labels12:10:0012:20:0010Partha turaga Partha presenting. [discussion] Greg Mirsky/Ericsson: Async BGP does not allow TLVs, but if that is of interest, we could consider applicability of BGP echo. Greg: there is also LSP self ping that could be aplicable here. Greg: I think the scope of this work should be formulated better - there are enough protocols that could do this. Partha: we are not adding more protocols. Greg: As I read your draft you are asking for a special purpose label value allocation. I do not see a need for that. Kireeti Kompella: what would happen if you send this on a broadcast network (say, a switch?) Partha: I have not considered that yet. Kireeti: It might be interesting from the saturation of the link piint of view that the responder sends two packets. Receiver could add one more packet to really saturate the link. George Swallow: my concern is that there are platforms built that siport global label space, and what you describe here will require hardware that is not capable of punting to the RP in order to support this. Would suggest using different labels for different interfaces. Partha: Not certain whether I can answer that. If we have per interface labels we need a mechanism to exchange them. George: Yes. Partha: that likely will result in a label distribution protocol functionality? George: that could be done in discovery phase. Partha: I also considered the mechanisms with ipv4 ... Shahram Davari: why cannot you use MPLS loss measurement instead? Partha: are they sending probes on those links? Shahram yes. Partha: I need low time intervals. Are you suggesing to use MPLS loss measurement instead? Shahram: MPLS loss measurement works by counting the loss counters. Loa: we are at the point where we need to take this to the list. Adrian proxying for Stewart Bryant via jabber: why not to do this with a large stack of labels? Special label is a hardware function. Agree with what George said. Partha: is there is a specialized label protocol? Adrian: Stewart is not talking about label distribution, he is talking about label stack. 11draft-chandra-mpls-ri-rsvp-frr12:20:0012:30:0010Vishnu Pavan Beeram Pavan presenting. [discussion] No questions and comments. ---------------------- Adrian proxying jabber room: Did you close the meeting 15 minutes early and have cut the mike lines multiple times? Do you want to invite those people to speak now? Loa: no, the meeting is closed.