WG Status co-chairs, 20min draft-ietf-mpls-ldp-multi-topology-04 Daniel King, 10min Dimitri: concerning the label space allocation process. nothing is being said in the document. Do you assume same label can be associated to multiple MTIDs? Dan: yes Dimitri: So how do you make distinction at forwarding level? Dan: we had an early discussion on that and did not feel to be an issue but will take that as an action to authors Quintin: we used to have two options: global space for all topologies or one space per topology but now only global space so no distinction problem Dan: maybe worth to have the discussion on the list again draft-ietf-mpls-tp-ring-protection-02 Daniele Ceccarelli, 10min Ready for WG LC. no comment/question draft-chen-mpls-p2mp-ingress-protection-06 draft-chen-mpls-p2mp-egress-protection-06 Huaimo Chen, 10min Nurit: generalizable to point-to-point? Huaimo: yes Nurit: should look at inter-domain as well Eric R.: only for IP packets behind the label or more general? egress may not understand inner label if there are multiple and some applications may stop working here ?: less than 50ms recovery, but what about detection time? Huaimo: bfd is used for failure detection ?: for egress protection you need to take into account service label. so similar question than Eric. Huaimo: we can extend protocols to deal with that or via configuration otherwise Eric G.: asking for WG adoption of both documents? Huaimo: we can progress them independently ?: how do you handle mis-merges and cross-overs? Nothing is said in document? Huaimo: with bypass tunnels we would not have mis-merges ?: not sure my question was answered, let's take it offline Dimitri: you need to document corner cases draft-torvi-mpls-rsvp-ingress-protection-00 Alia Atlas, 10min Richard Li: does backup node always get the traffic? Alia: backup and primary need to be connected but backup not always receives traffic. dependant on the failure detection mode Richard Li: how do you know of the failure of the primary? Alia: you are not dependant on a connected link. Getting it right that the ingress is down with respect to one particular MP is non trivial George: purpose of proxy ingress? Alia: ingress does the signalling for proxy ingress in all cases different IP address used in case need to do reoptimization Lou: both drafts (this one and previous) are interesting in the sense that they use RSVP to coordinate with an application running on top of rsvp. New application of the protocol that I do not think we have seen before. PCE closest thing to that. But does RSVp make sense? Alia: agree there is coordination but it is not so much application specific. more generalizable than egress protection. Lou: are you suggesting to propose this as a generic mechanism with egress protection being the first use-case Alia: I am not trying to solve egress protection with this. for the ingress protection you could generalize. Ross: authors and interested parties to get together. bunch of offline work is needed. draft-zjns-mpls-lsp-ping-relay-reply-00 Thomas Nadeau / Ryan Zheng, 10min ?: [missed] Richard Li: only works for rsvp-te tunnels? Thomas: no, generic lsp-ping operation. Richard G.: suggest you add an informal reference to the operations document on filtering ICMP v6 in the Security Section draft-xu-mpls-in-udp-02 Xiaohu, 10min Eric R.: have you been to PWE3 to ask for a new encapsulation? James Kempf: do you know anybody doing products implementing this? Xiaohu: it is new proposal James Kempf: then I recommend dropping this. IETF does not need a new standard that nobody implements draft-weingarten-mpls-smp-requirements-00 Sam Aldrin, 10min Dave A.: as contributor, we are still late on requirements that would justify new protocol work beyond what we have. request to service providers to speak on the list draft-lzj-mpls-receiver-driven-multicast-rsvp-te-01 Richard Li, 10min Eric R.: what is this for? is there something here that you can not do with mLDP? Richard Li: you could use mLDP. But three reasons to use this RSVP-TE is deployed in my SP network. I can do traffic engineering and control the path Eric: you won't have TE with egress driven ?: the receivers that compute the TE path, how do they know the global constraints? Richard Li: by configuration ?: receiver come and go. who is responsible for the reoptimization Richard Li: not discussed in draft Lou: you mention PIM is the application, is that correct. Richard Li: PIM is one application, a document will be presented Lou: would be better to present it before draft-zlj-mpls-mrsvp-te-frr-00 Katherine Zhao, 10min ?: I do not see why existing PR driven signalling would not work? Richard Li: here path is set from MP to PR and not from PR to MP draft-pdutta-mpls-multi-ldp-instance-00 Pranjal, 10min Richard Li: two parallel sessions only work when 2 different address families Pranjal: would also work with single address family ?: what will be the mechanism of choosing LDP ID in this case? and how to ensure IDs are different Pranjal: implementation specific On draft-ietf-mpls-ldp-ipv6-07 Pranjal, 10min Eric G.: I do not agree with point on slide (multiple adjacencies to the same peer is a violation of RFC) it is having multiple adjacencies with two LSRs sharing the same ID which is impossible Pranjal: correct Richard Li: could you use 2 different TCP ports? Richard Li: Hellos are not essential for this case Pranjal: they are Ross: Are you proposing there should be a change to draft-ietf-mpls-ldp-ipv6 ? Pranjal: yes Ross: the draft is not yet submitted to ADs. WG need to resolve this point quite quickly now Pranjal: agree Matthew B.: rule in the document about advertising FECs of same add family as the hello adjacency but PW FECs are of address family L2VPN. So the draft is ruling them out. George: I would agree this broken. We clearly need to get consensus before we progress document **** Friday Session **** draft-tao-mpls-pim-interworking-00 Robert Tao, 5min Thomas morin: a draft already exists to tackle what you mention Also, the seamless mcast working group draft goes beyond what you plan you should read these two documents Robert: yes but outband approach Thomas: you would need to explain why you need a new approach ?: you still need these protocols. you simply described a proprietary interface inside the PE George: would like to hear from people building l3vpns to say if they need this additional solution Issues with deep label stacks Kireeti Kompella, 20min George: it does not relate to entropy labels except for the fact that they make the stack deeper George: not so much about the number of labels in the stack but those on which to hash Pedro: I have been involved chip specification on transit: look for 3 labels, look for BoS, then IP header, hash on it. chip do not drop packets, they do not do load balancing if they do not find BoS chips would be happy with stacks no deeper than 3 George: some go deeper Jeff: usually if you can hash on 4 labels it is good enough Kireeti: the question here is: is there a problem with deep label stacks? It is a separate problem than entropy labels. Pedro: if you can signal the chip that there is an EL, then that is fine Kireeti: we do, with the ELI Sharam: happy that you bring this issue at IETF the main point is doing many (5, 7) look-ups, so deep label operations, not deep label hashing. Also, reserved labels are not important from that point of view Ross (as co-chair): the issue I have is what does the group want to do? Sharam: if you can do 2 PHPs that would already be good. Kireeti: we can with LDPoRSVP-TE DaveMcDysan: is there potentially a research problem here? George: when we started tag switching we thought of this and finally decided to make a stack Stewart: we may end-up setting an architectural restriction on the number of labels that can go in the stack which would be catastrophic Kireeti: we thought of multiple BoS but did not want to go there Stewart: you could envisage architectural reasons for doing so George: I would argue with you Ross: who thinks there is an issue here that is worth some form of a document? result: good number of hands Ross: who thinks there is not a problem? result: ? Pedro: should this go in the entropy label document? George: we should try not to break existing deployments Stewart: isn't it what capability signalling about? George: yes, but then you have people not willing to upgrade the software Stewart: so they can't have the service George: my point is that we should not break the service Ross: we have seen a show of hands that tend to say there is an issue that should be investigated further you have already received some feedbacks you might not want to write the doc alone draft-fuxh-mpls-delay-loss-te-framework-05 Dave McDysan, 10min Adrian (as voice for jabber): There has been discussions on whether mpls is home for this work. if mpls accepts the document then it means it is. Dave: was in ccamp but then moved to mpls. this is an AD question Adrian (as himself): doesn't it bother you that your draft gets ping ponged? Adrian (as AD): I would ask you to look at whether you have just a couple of parameters (loss and delay) or if you want a generic mechanism that would allow others to do other things in the future That would be the threshold between mpls and ccamp Adrian (as Lou Berger on jabber) happy to do it in ccamp, but thought it was in mpls Dave: my recollection as well Adrian: so you have a home, you just do not know which it it. Imanshu: have you considered a dedicated DM or LM running on the LSP either to monitor or measure and then reoptimize? Dave: we thought about something along these lines Andy (as co author): concerning the home, are you looking to co-authors to make this decision? George: decision is between chairs and ADs Ross: but that should not be blocking, continue to update Dave: Chairs and ADs may want experts’ opinion George: we will make decision, we will get inputs draft-li-mpls-ldp-mt-mib-03 Lilianyuan, 10min George: how many have read. result: not very many Please read before next meeting and comment on list draft-hmk-mpls-tp-p2mp-oam-framework-00 Yoshinori Koike, 10min George: we will discuss this document and next one together draft-fbb-mpls-tp-p2mp-framework-05 Stewart, 10min Andy: There was a liaison from SG15 expressing support for this draft and would like to see it go forward. George: not only "go forward" but "go forward soon" Stewart: as soon as you tell us we can do this, I'll change the name if you tell us we can't then we need detailed inputs to move forward. George: We got our requirements from ITU. However I would like p2mp bidirectional to be considered instead of only unidirectional If there is a return channel, we could apply all te stuff we have done in a much straightforward way Stewart: That does not prevent from making it a WG document? George: did you here say me that? Stewart: no George: how many have read? Not as many as I would have liked. Out of them, how many think it is ready? Same number Encourage more people to read it. I am inclined to poll it prior to next meeting Ross: to Yoshinori, how do you feel about merging drafts? George: Stewart proposal was not a merger but a summary in draft-fbb Yoshinori: would be happy to be co-author, and put a summary George: I would like the summary to incorporate p2mp+return path