WG status 09:00 chairs, 15min Loa: all time record 10 new RFCs draft-ietf-mpls-tp-li-lb & draft-ietf-mpls-tp-on-demand-cv depend on each other so AUTH REF should not be an issue MPLS-TP feature developments and interoperability Bijan, 10min 09:11 no comment/question draft-ietf-mpls-return-path-specified-lsp-ping-04 Mach Chen, 5min 09:21 Sri: applicable to mpls-tp also? Mach Chen: to both mpls and mpls-tp Sri: but no support for non IP identifiers Sri: applicable to p2mp? Mach Chen: no draft-ietf-mpls-tp-itu-t-identifiers-02 Rolf, 5min: 09:27 Adrian: thank you for this work. We sent a liaison to ITU-T to get confirmation that the Normative references are the right ones. I don't think this is blocking, but are we confident we are doing the right thing with the right docs? Rolf: yes Lou: when will this doc be moving forward? George: not sure because I want to see references from the itu would prefer to keep all identifiers in one doc I understand there is nothing blocking You should have a LC before next ietf Huub: 1731 was approved and shall be published soon. Reference is 1731 Ammendment 1 George: Please post it on the list draft-ietf-mpls-entropy-label-01 Kireeti, 10min 09:33 George: are you moving towards standardizing ecmp algorithms? Kireeti: no, this not about hashing algorithms George: how do you map services to lsp Kireeti: up to edge device. Stewart: the apps can identify the flows, the tunnels have no clue of that. how could you do it? Kireeti: signal on LDP LSP that will accept entropy labels, at the edge you know the app and you put the entropy label but not at the bottom of stack, you put it closer to the tunnel label draft-ietf-mpls-ldp-multi-topology-01 Quintin Zhao, 10min 09:43 Ice: whatever we choose we should strive to align it with mldp [?]: concerns with draft, we must first focus on how to use the multitopology TLV from a forwarding perspective if we skip that I do not understand how we can end-up with something useful Quintin Zhao: we had options of global space labels or or a space per topology now, moving towards global space Dimitri: should add text wrt to loop detection and on how you update the ldp spec draft-ietf-mpls-tp-te-mib-00 draft-vkst-mpls-tp-oam-id-mib-01 draft-vkst-bfd-mpls-mib-00 Sam, 15min 09:54 George: on draft-ietf-mpls-tp-te-mib-00, need wider discussion on list on how we configure mpls-tp. There were suggestions for using netconf Tom: we had a long discuss on the list already. what was the conclusion? did not recall a decision Ross: chairs need to have deeper look at the conversation. don't recall a clear consensus we can't force you not to do the work you do want to do neither. WG need to figure out what are next steps. Kam: on draft-ietf-mpls-tp-te-mib-00, did you update? Sam: no, same version as in Quebec Adrian: on draft-vkst-bfd-mpls-mib-00, would it make more sense to ask wg adoption in bfd wg rather? Sam: should formulate differently indeed Tom: also because rumour that bfd wg is going down Adrian: should to to the AD because he has never heard it draft-allan-unified-mpls-ic-req-frmwk-00 Dave A., 15min 10:06 George: all things are possible but not all are useful should identify gaps and then identify what's worth doing Dave: that would be a natural outcome George: if you plan on connecting any to any, you'll need a good security section Lou: already a bunch of RFCs on this topic, e.g., 5146 Should have a look at these? ?: do you suggest that only solution for cc/cv in tp is bfd? Dave: that certainly facilitates capability negotiation draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Ice, 5min 10:15 [Jeffrey ?]: need for discussion in L3VPN first Ice: disagree, we did the same for recursive fec, but I can definitly present at L3VPN Ross: chairs (of mpls and l3vpn), and ADs need to get together to define a home draft-fbb-mpls-gach-adv-00 draft-fbb-mpls-tp-ethernet-addressing-00 Stewart, 10min 10:22 Greg Mirsky: I sent a question on authentication to the list. Is authentication assumed to be always present? Diffeent ways to do it, tlv, flag ... Can requests be sent only for bidir entities or unidir possible and would require DCN for reply Stewart: Request is an optimization, in case you have not seen a beacon for a while pplicable to both constructs if indeed you can have the reply Note that only intended for immediate adjacencies (1hop) But do you think it is useful? Greg: yes Jonathan Sadler: agree also this is useful, but why new protocol and not lmp? Stewart: please propose how would that work [?]: can we use this new protocol to do the refresh reduction that the PWE3 refresh reduction protocol does? Luca (rephrasing): can we use PWE3 refresh reduction? Stewart: le's talk about it Luyuan: I don't think it is the same application George: on draft-fbb-mpls-tp-ethernet-addressing-00, my opinion is that it is extremely usefull draft-zj-mpls-lsp-ping-reply-relay-00 Ryan Zheng, 10min 10:32 Greg: assumption that address type is consistent (either v4 or v6) through out nodes traversed Ryan Zheng: yes Greg: realistic case? Ross: let's discuss offline on the v4/v6 topic draft-zhao-mpls-mldp-protections-00 Quintin Zhao, 10min 10:40 Alia Atlas: this in scope of rtgwg, rechartered to cope with hop by hop mechanisms also, your draft does not talk about the algorithms George: you have been invited to present this at rtgwg draft-liu-mpls-tp-interconnected-ring-protection-00 Liu Guoman, 10min 10:53 Eric Osborne: this draft argues that there are ring specific mechanisms you are going to develop? Liu Guoman: yes Eric Osborne: Need to define what is not a ring. we have mesh protection and looks like a lot a meshed network. need to see why existing mechanisms do not apply. Liu: this draft is not a solutions document Eric: not asking for solution, but scope Kam Lam: is it mpls and/or mpls-tp? Liu Guoman: mpls-tp draft-minto-2547-egress-node-fast-protection-00 Hannes, 10min 11:00 [?]: similar mechnisms elsewhere. could we have a unified name to such kind of protection? wim: how does it work in case of mcast? Hannes: you fix the unicast tree Wim: a source connected to PE you have anycast adresse the reciever pe needs to knwo the which adress to take and how do you provide fast failover on that leveel would be good to add that Hannes: so say that mcast is oos for that draft? Wim: ok [?]: advantage of protector to be any other box than the back-up PE? Hannes: The redundant PE is natural choice for protector PE, but that is not a deployment must The must is that the PLR must be able to construct a local repair path to the protector, anytime. So, the protector can any node as long as you have 100% coverage draft-bitar-mpls-isis-explicit-null-label-00 Nabil, 10min 11:12 Greg: have you considered using G-ACh? Nabil: was considered but no reason to do so; Greg: you are doing protocol signaling here, and that's one of the purposes of the G-ACh Kireeti: why S bit to 1? This is unecessary constraint Luca: you are using a label for a protocol id, bad idea. why the packet pw was a bad idea? Nabil: assumption of reference model is different compared to the one of packet PW George: we need to take this on the list in 16 years we have only used 6 reserved labels draft-kompella-mpls-rsvp-ecmp-01 Kireeti, 5min no comment *** end of Monday's session *** 15:22 Word from the chairs: 6 new RFCs since monday! draft-beckhaus-ldp-dod-01 Maciek, 10min 15:25 Sri: queing of the request should hold on the restart of the dLSR Maciek: yes, that would be the assumption George: how many read the draft? George: you might need to have few more people reading the draft draft-raza-mpls-ldp-applicability-label-adv-01 Sami, 5min 15:34 George: informational? Sami: yes George: so if updates the rfcs mentionned then must be standard track thus few more loops needed George (chair hat off): ack the inventors of LDP draft-fuxh-mpls-delay-loss-te-framework-02 draft-fuxh-mpls-delay-loss-rsvp-te-ext-00 Xihua Fu, 15min 15:40 George: not going accept new kind of work until we recharter Is current loss of a path relevant if you plan on adding big TE LSP in addition? Eric O.: service aware framework does not match the content (delay, jitter, ...) Plan on extending the content? Xihua Fu: yes Ross: continue via e-mail 2nd draft Lou: changes concern IntServ. should be done maybe in tsvwg I support the objective but 100% in scope interv and out of scope of rsvp Ross: good question. need to be resolved offline Xihua: was in ccamp, now moved to mpls, but not sure rsvp is good place indeed Loa: decision will involve serveral chairs and ADs draft-chen-mpls-ipv6-pw-lsp-ping-02 Mach Chen, 10min 15:55 Ross: did you present in PWE3 this meeting or previous IETFs? Mach Chen: this time George: how many read? Some Please read I think this actually fits in our charter draft-pdutta-mpls-tldp-hello-reduce-02 Tom, 5min 15:59 [?]: provided comments to that doc what is your primary concern: security or resources Tom: the latter. security is a side effect George: this protects again self-inflicted DoS attacks Ross: how many have read? more than the last few times Ross: how many think it is ready? pretty much the same number Ross: ok, we'll take this to the list draft-ietf-mpls-tp-security-framework-02 Luyuan, 5min 16:04 Loa: WG LC just closed draft-fang-mpls-tp-use-cases-and-design-04 Luyuan, 10min no comment/question draft-jin-mpls-mldp-leaf-discovery-03 Lizhong Jin, 10min 16:17 Ross: how many have read? few Ross: how many think it is ready? almost as many Ross: ok step in right direction draft-jin-jounay-mpls-mldp-hsmp-04 Lizhong Jin, 5min 16:22 Ross: how many have read? not that many Ross: we need to take this to the list draft-koike-mpls-tp-temporal-hitless-psm-04 Yoshinori Koike, 5min 16:26 Loa: this is ietf, we accept individual draft to the wg, this is not a company document How many have read? fair number how many think it is stable enough? about half Back to the list Shared mesh - common 16:35 Sam draft-pan-shared-mesh-protection-02 Ping, 10min 17:39 Allan: posted a draft on packet label preemption rather than on path preemption Suggest to have a look at it Greg: what does it activate? Ross: let's have Yaacov present before open discuss. draft-cheung-mpls-tp-mesh-protection-04 Yaacov, 10min 16:45 George (off): we are reinventing a control plane Greg: on draft-pan-shared-mesh-protection-02, you talk about path activation? please clarify activation and encapsulation Ping (to George): we do not need any control plane Ping (to Greg): [missed] Adrian (off): we are inventing a control plane protocol George: thank you for the clarification [?]: on draft-cheung-mpls-tp-mesh-protection-04, how does B learns the SSNs, SENs? Yaacov: through some kind of signalling at time of set-up [?]: how B knows U is SEN? Yaacov: an lsp between B an U must exist [?]: that is not in the draft Yaacov: right Ross: to what extent does it appear the drafts will be combined? Yaacov: we had a conversation. Seem to be making progress. Need to understand the different protocols and state machines. Ping: we do not understand how Yaacov draft works Greg: you state that it takes one message to activate any protection? How do you activate SMP for associated bidir LSP? Ross: considerable amount of work to go through all these issues please work together and report back to the list draft-chen-mpls-p2mp-ingress-protection-04 draft-chen-mpls-p2mp-egress-protection-04 Huaimo Chen, 10min 17:00 Greg: I have sent comments and had discussion Still believe not local protection but redundancy and thus in scope of PWE3 Huaimo Chen: PW and LSP protections operate at different levels Greg: you run oam between CE and some P, thus my position Huaimo Chen: other methods could be used Greg: which one? Huaimo Chen: bfd Greg: bfd is oam Ross: requesting adoption for both drafts? Huaimo Chen: yes George: we should differ decision due to rechartering *** if time permits: draft-kini-mpls-frr-ldp-02 Sri Stewart: do you plan to push as many labels as it takes to go around that node? Sri: there is not stacking of label. labels per segment to circumvene the failure Stewart: understand Ross: Not sure in our charter. Would like to check with rtgwg Stewart (as AD): hop by hop procedures happen in rtgwg Sri: ok I can go & present there loa: as soon as we start touching ldp, I guess mpls would be a good place for this Stewart: of course we consult appropriate WGs, extensions would need to be reviewed here loa: I would in fact be concerned by ldp changes happening in different places