Wednesday, Morning Session I, 09:00-11:30 Thursday, Afternoon Session II, 15:10-17:10 *** Wednesday session *** WG Status 09:00 (09:05) co-chairs, 15min Stewart (on Ethernet addressing): we are ready to go. if anyone thinks I missed something, please bring it forward George: if something significant was missed it won't go immediately to LC Huub (on identifiers): one more revision to be published Huub (on rosetta): we still have to consider one MPLS-TP framework draft, then some clean-up and publish. Only then ready for WG LC draft-ietf-mpls-ldp-multi-topology-05 09:15 (09:24) Quintin, 5min Quintin: Ready for WG LC Curtis: 24 and 25 Types, are these IANA assigned? Quintin: no Curtis: you are not supposed to give numbers then George: Dan King set-up an informal registry in CCAMP so that people can pick some values, avoiding conflicts. Discussed with Dan on doing the same in MPLS, yet you might nit end up with the selected value. Curtis: I would prefer the use of TBDx and in IANA section say "TBDx equals to ..." George: I would prefer TBAx Ross: Request on behalf of Loa who is listening, could somebody join jabber? draft-li-rtgwg-ldp-mt-mrt-frr-00 09:20 (09:32) Quintin, 10min George (at 09:41): this was already presented in another WG. Although we have extra time, we want to give room for discussions so please try to wrap-up rapidly. George: if want to discuss this, please go to RTGWG. draft-frost-mpls-test-session-00 09:30 (09:43) Dan, 10min Greg: Agree this is a great idea & good timing but I think signalling approach would be a better approach Dan: which? Greg: RSVP-TE or LDP Dan: format of packet is left open Greg: so why not use existing protocols Dan: because the need come from people interested in MPLS-TP Greg: they will use NMS Lou: it seems you are defining a third signalling protocol. Does this make sense? Dan: in a sense yes we are defining a signalling protocol but not as heavyweight as RSVP-TE We could limit that protocol for test stream also. Lou: we already have directions for solving this type of problems NMS for people not wanting to use signalling and signalling for people not wanting NMS. Also, RSVP-TE started with the target of being a lightweight protocol draft-lim-mpls-proxy-lsp-ping-00 09:40 (09:52) George, 10min Ross (as chair): how many people have read? Result: 4 or 5 Please read the draft draft-villamizar-mpls-forwarding-00 09:50 (10:06) Curtis, 10min Carlos: I have not read the document. Seems interesting and useful. With regards to packet rates. This is a tricky area. First there is an RFC on performance metrics for MPLS forwarding, second you should reach out to the Performance Directorate Curtis. I did, but this is not a benchmarking methodology document. It is said in the document. Carlos: ok Stewart: Do you have the work of Kireeti on special purpose labels as a Normative Reference? It would be good that the documents be in synch. Curtis: Good comment. Will do so. Shane: This is good work. I will post my comments on the list. Hannes: I did not see any mention to recursive label lookups Curtis: this seems like an implementation issue. It should be taken on the list. [?]: You mention UHP, is counting each label separately required? Curtis: yes [?]: so would you say this requirement is optional, mandatory? Curtis: it depends if you consider MPLS-TP optional George: The impact of MPLS-TP is wider than MPLS-TP there is a lot more interest in analytics, in what's going on in the network, hence counters. As a chip vendor you can decide to address that market or not, but that market is becoming a reality. Stewart: Not just about counters George: It was just an example Ross (as chair): please read this useful document draft-kompella-mpls-special-purpose-labels-01 10:00 (10:22) Kireeti, 10min Andy: do we see the need to retire labels, knowing that we'll now have many? Kireeti: there needs to be a process and it needs to be heavyweight because it is encoded in hardware, even if we do not use it. Having a process is not a problem, making it lightweight would be scary. Philip Matthews: do we want to generalize this approach and extend the overall label space, e.g., by adding a bit in front of the 20? Kireeti: every bit has a meaning, so it seems difficult. Lucy: do we really need to expand the special label space? Stewart: the sooner we make the arrangement the better. It takes time to move things into hardware and we need to prepare MPLS for the future. Eric Rosen: we'll now have much more reserved labels. I do not understand this notion of preparation. why not do that when we'll need these labels. Ross: take this good discuss to the list draft-kompella-mpls-rsvp-ecmp-02 10:10 (10:36) Kireeti, 15min Igor: couldn't you do this with bundles? Kireeti: intermediate nodes should know about the relation between LSPs. I am not sure how bundling would work but as long as nodes know it would be fine. Sam: When do you consider the LSP down? Kireeti: When no path exists anymore. Sam: if 10 sub-lsps for example, all of them have to go down? Kireeti: similarly to LAG you could consider the construct down when a given number of sub-LSP are down. That is configuration. Sam: are sub-LSPs elastic? Kireeti: yes, but there is a practical limit to augmenting bandwidth of an LSP Sam: so do you still think the FRR could be achieved? Kireeti: yes, until a certain point. George: you could potentially be changing the semantics of how we do re-grooming with LSP ID. This needs to be worked out. Also there could be another approach which would be to have a sub Tunnel. Kireeti: Possibly Hannes: on sub lsp slicing. how would that work if i want to slice P2MP LSPs? K: do you really want me to answer? Hannes: I was just emphasising that association is a good track. Kireeti: [missed] [?]: ECMP is using hash based techniques, there are large flows and small flows so hashing is never perfect so it is not true Traffic Engineering Kireeti: ECMP is not perfect, TE is not perfect, what you say is that they could happen together, so be it draft-zhao-mpls-mldp-protections-03 10:25 (10:55) Quintin, 10min Ice: there is a draft in RTGWG which describes similar procedures based on MRT I would encourage you to read it and remove any duplication Quintin: We did discuss this. Here, our focus is on mldp node protection and could be extended to e2e protection easily. This draft is not specific to MRT itself. For the overlapping parts we could decide which draft could be the home. Ice: this is why we did not specify the extensions. we need to get the architecture right before and then spin drafts in appropriate document/working groups George: take the rest of this discussion to the list draft-minto-rsvp-lsp-egress-fast-protection-01 10:35 (10:08) Hannes, 10min -no comment/question- draft-shen-mpls-rsvp-setup-protection-01 10:45 (10:17) Yimin Shen, 5min Greg: what guaranties that your FRR has the same characteristics than your pre-computed path? Yimin: basic bandwidth could be satisfied using flags Greg: not being able to signal the path is quite a normal situation because of local changes Yimin: Here we are addressing the specific requirement of signalling needing to be done immediately Greg: why do extensions if you could do differently? Yimin: you want to serve demand rapidly, then you could do things more globally Nurit: same comment than Greg, not sure this is the best approach from a network utilisation point of view Yimin: here we can not tolerate delay, so you do things rapidly. Then you fix your link or switch it to stand-by lsp. Imanshu: does it address node failure also? Yimin: Yes. Based on ERO. Imanshu: I do not see how this would work then. if the node never participated to the signalling, you can't go through that node, the label was not exchanged. There would need to be a new signalling Yimin: right, new signalling will happen Lou: once repair happens, a new state will be populated in intermediate node and if that successful traffic will flow, but what if signalling fails? Yimin: traffic do not goes back through recovered failed node until signalling has happened Lou: but what if signalling fails? Greg: suggest PLR will hold on signalling and not tell anything to head-end George: closing *** end of monday session *** draft-chen-mpls-p2mp-ingress-protection-07 15:00 (15:11) draft-chen-mpls-p2mp-egress-protection-07 Huaimo Chen, 10min Huaimo: is draft of Alia addressing same problem than the ingress-protection? Yimin: Alia is not here, but yes there is overlap. May need to merge. Ross: a good first start is that authors get together so as to see what each draft does, what are commonalities and differences. Huaimo: there is a draft presented in PWE3, similar to the egress-protection. Do the authors intend to resolve same problem as my draft? Yimin: for egress protection you have to protect the service so two labels the draft presented yesterday is a generic framework for egress protection so they are companion documents rather than overlapping ones Also your draft is not addressing service level and it focuses on p2mp Huaimo: mechanisms could be the same for p2p than for p2mp. Also, applicable of multiple levels of labels Yimin: how would it apply to service label Huaimo: we did not include this in the draft Greg: both documents are missing security considerations section. If work continues, I would suggest to add it Ross: you will want to get together with other authors, as well as have discussions on the list Huaimo: do yo think we tackle same problems for the egress protection George: you would need to explain what else has to be done unless you restrict this to IP traffic draft-cheng-mpls-tp-shared-ring-protection-00 15:10 (15:29) Hui Deng, 10min Nurit: you are talking about a construct I am not familiar of, which is a ring LSP Also you depict multipoint to multipoint connectivity and I am not aware of such thing in MPLS-TP Also you come with an alternative proposal to existing document. According to RFC you should indicate how much better you perform so as to justify the alternative solution, and I did not see that. Finally I find steering very complicated from an operational perspective, as you need to update mapping tables in every node each time topology changes. Greg: I second Nurit's comments. In my view, what you refer as a ring tunnel is an SPME. In the text you only mention single ring while you state that it addresses interconnected ring. Your scope is P2P but you implicitly assume it is bidirectional even though unidirectional is part of MPLS-TP, so it would be interesting if you could extend to unidirectional P2P LSPs You stress that you use link OAM to detect the failure, but link OAM for the steering requires coordination, so it is unlikely you'll reach the performance that you state and in my view segment OAM addresses steering better Also, it is not explicitly stated whether you desire link or node protection for the wrapping, that decision has to be made upfront so it is predetermined Coordination protocol is missing and I hope you will add it later Hard to see why this work is better than existing solutions Hui: As an answer to one comment, the RFC does not say one must not do mp2p Also, I am not the author, I hope minutes are taken so that question can be answered Ross: a detailed discussion is a sensible thing to have on the list draft-villamizar-mpls-tp-multipath-03 15:20 (15:44) Curtis, 10min Lucy: does the draft proposes to allow tp-lsp to go through multiple paths? Curtis: if a mpls-lsp goes over multiple paths and you decide to carry a tp-lsp over then you use the entropy label so that the tp-lsp uses only one path for a given tp-lsp you would give it a single fixed value for the entropy Lucy: confused by the client layer which could be bigger than server layer Curtis: if mpls-lsp is client to tp-lsp, tp-lsp can not be bigger than link but the mpls-lsp could so you would have to split the mpls-lsp at the ingress in multiple tp-lsp Document describes requirements and how to meet them but without change draft-villamizar-mpls-tp-multipath-te-extn-02 15:30 (15:55) Curtis, 10min -no comment/question- draft-balaji-mpls-csc-te-lsp-splice-01 15:40 (16:08) Bhargav Bhikkaji, 10min Dave: I'll present later a draft that presents aspects of performance that may be relevant to your work Lou: which problem are you trying to solve? Bhargav: Advertize LSP characteristics in BGP for another PE to use it, kind of BGP forwarding adjacency. Ross: how many have read? George: I have but did not fully understand Ross: This is somewhat difficult to fully grasp from the presentation so I encourage people to read it Lucy: [missed] Curtis: why not use hierarchy? Are you proposing to use stitching? Hierarchy would solve this. Tier 1 edges could be made adjacent simply by a TE LSP Bhargav: we did not find such kind mechanism Curtis: you do not have to change anything, it was done years ago Bhargav: no we do not touch any thing between Tier 1 edges, we want to pass information between Tier 2 edge Curtis: but the end goal is ldp connectivity between PEs across Tiers 1, and that is already a solved problem so why not use the existing solution. Ross: take discussion to list draft-li-mpls-serv-driven-co-lsp-fmwk-00 15:50 (16:21) Zhenbin, 10min Nurit: only the edges are aware of the relationship between the two unidirectional LSPs, is it? Zhenbin: yes Nurit: so it will not solve the issue presented at the beginning and so I do not see the benefit. Also, service driven is confusing. TE-LSPs typically aggregate multiple services. Ping: it is a very useful application, and a similar proposal exists in PWE3 WG. Lou: co-routed seems misleading. I think what you mean is associated bidirectional LSPs that follow the same path if you avoid the co-routed term, it would be less confusing Zhenbin: yes, we need to work on terminology Ping: I think it is solving the right problem but we need clarifications on terminology and problem statement Imanshu: yes, it should be associated because in co-routed the intermediate nodes know about the forward and backward LSPs and this is not the case here Seems like you are triggering the LSP creation via the pseudo-wire signalling using the PSN bidding TLV, is that correct? Ping: he is trying to use mp-bgp to communicate the association information George: continue the discussion on list. Also there is a draft also in CCAMP on associated bidir Zhenbin: we do not need to modify RSVP-TE signalling, but to use MP-BGP Lou: if you use the CCAMP associated bidirectional extension then you satisfy the recommendation of having the intermediate nodes understand the association so you do not need this extension but if you allow for it you better meet the MPLS-TP requirements. Ping: this is for mobile backhaul, so why would you want to use the CCAMP Association extension draft-hmk-mpls-tp-p2mp-oam-framework-00 16:00 (16:36) Yoshinori Koike, 10min George: In sc1 your forwarding plane is set up to all leaves, if you do something to test a subset of leaves then you are no longer testing your forwarding plane Given the size of traffic flows, and the oam in comparison, why not setup a reverse tree for the return path? Adrian (as indiv): we went through that and looked at these options and choose to either ping the whole tree or only a leaf but ruled out pinged a sub-set of leaves because the extensions for this became unmanageably large Yoshinori: from implementation perspective, the easiest way may then be SC3 (NMS based) Lou: I understand you are focussing on updates, because you have not said you have removed it, I presume the return to head-end still case is still here? Yoshinori: yes, as an equal option Lou: in the general framework document, we say TTL can be used to control distribution. you may want to think about it in the context of your different scenarios George: for LSP-Ping we found TTL quite useful Lou: this is why we put it in the general framework document Yoshinori: we could use TTL if trying to reach intermediate points Ross: cutting. In abstract you mention a possible merge with another document. You could discuss this also on the list. draft-fuxh-mpls-delay-loss-te-problem-statement-01 16:10 (16:50) Dave McDysan, 10min Lou (ccamp co-chair): we are ok with it being either place (MPLS or CCAMP). If MPLS do not want it, we are happy to take it. Imanshu: this is an interesting problem. is it even possible to get from each node, per link the latency, delay variation and stuff like that in real time? Ross: I apologize but we won't have time to answer that. Dave: there is some text in the draft, have a look at that and ask the question on the list. Ping: I support this draft. Mechanisms for getting the information exist, but we just need a standard way of getting it. [?/BT]: We definitely see this as a problem. I'd be interested in contributing to different use cases Ross: ADs to decide which group, as chairs of both groups are ok to have this document in their respective groups draft-fuxh-mpls-delay-loss-te-framework-06 Dave McDysan, 5min - not presented - draft-xu-mpls-in-udp-03 16:25 (17:04) Xiaohu, 5min ready for adoption George: there are considerable security issues that need to be sorted out before we can think of polling for adoption Xiaohu: Security is much simpler(?) for MPLS in UDP than in GRE, also MPLS in UDP is intended to be deployed in closed environment like a data center Lucy: we will address this in next revision Ali S.: this draft is intended for data center. I'd like to hear from data center operators regarding this encapsulation especially knowing that they are moving towards VxLAN and NVGRE George: at time of adoption, feedback from operators is highly regarded.