Minutes for MPLS at IETF-89
minutes-89-mpls-1
Meeting Minutes | Multiprotocol Label Switching (mpls) WG | |
---|---|---|
Date and time | 2014-03-06 15:20 | |
Title | Minutes for MPLS at IETF-89 | |
State | Active | |
Other versions | plain text | |
Last updated | 2014-03-12 |
minutes-89-mpls-1
*** highlights start *** + WG chairs need to clarify next steps for draft-ietf-mpls-tp-te-mib + take discussion on draft-chen-mpls-source-label-02 to the list. + WG Chairs to discuss with ADs the positioning of draft-chen-mpls-source-label-02 wrt on-going work in other groups + take discussion on draft-li-mpls-p2mp-te-alt-path-01 to the list + Clarify intended status of draft-tsaad-mpls-p2mp-loose-path-reopt-00 + draft-cui-mpls-tp-mfp-use-case-and-requirements-01: continue discussion on the list and flush out requirements + WG Chairs to launch 1-week WG LC on draft-ietf-mpls-ldp-multi-topology-11 *** highlights end *** -Tuesday- WG Status WG Chairs, 15 min Lou Berger: heads-up, FRR for bidirectional co-routed LSPs will be presented on CCAMP (Friday) There will be a discussion on where does this item fits as MPLS has designed FRR * Criteria for getting agenda slots George Swallow, 5 min (no slides) George highlighted the priorities according which the MPLS WG Chairs accept and order items on the agenda * MPLS WG processes Loa Andersson, 5 min -no comment/question- draft-tiruveedhula-mpls-mldp-mib-02 Vishnu Pavan, 15 min -no comment/question- draft-kompella-larp-00 Kireeti Kompella, 10 min Dan Frost: I like the work. But the problem space is much larger: general problem of mpls-uni Are you aware of draft-ietf-mpls-gach-adv? And have you considered using that as a potential alternative to using ARP? Kireeti K.: no, not aware and have not considered using that for this We selected ARP because every server has ARP. We do not want a full blown routing protocol but something Plug and Play Dan F. Makes sense. draft-ietf-mpls-gach-adv is super simple. ARP is super well known. Advantage of gach is a bit more extensible add TLVs) Kireeti K.: good point. In ARP reply, can give you label, and also metric. so can choose between two path in case multi-home but not want more complicated than that Stewart Bryant: As RTG advisor to sunset4. Concerned that we use a v4 only solution. Solution should be agnostic. The solution should work equally well with IPv4 and IPv6. This might point to draft-ietf-mpls-gach-adv or another solution but not to ARP. Kireeti K.: ok Lucy Yong: should the server implement the full mpls specifications? Kireeti K.: no, only add a label on the way out or capable to map label to vrf on the way in. This is not forwarding. Lucy Y.: is it between servers or ToRs? Kireeti K.: single label stack that I have pictured. but for scalability you might want to have ToR-to-ToR label and server-to-server label End of the session. Meeting adjourned by Chairs. -Thursday- Discussion on read-only/read-write MIBs in MPLS and specifically on draft-ietf-mpls-tp-te-mib Benoît Claise, 15 min A bit of history: RFC3535 contains the answers to IAB's question to operators on MIBs. Served as base to create netconf WG. Benoît presents the IESG statement If good reason to use SNMP set, feel free. Will never have a DISCUSS on this. Utilities for having SNMP set: consensus of the WG, extension of write module Take it as advice for future work. Think about NetConf/YANG. -Questions- George Swallow: SNMP has became to slow in getting a lot of information. Benoît C.: SNMP if fine for 5 minute counters. If you want to extract a lot of data/with high frequency, you can use ipfix to push a lot of data out of devices. Sam Aldrin: I am authors of draft that was sent back from IESG Benoît C. was not sent back from IESG. AD review led to some questions. Sam A.: ok Sam A.: we are not sure what we have to do as authors of draft-ietf-mpls-tp-te-mib. Read only or not? Read-write because the original TE mib is read-write capable and we extend that mib People said they implemented the write part of the TE mib. So, how should we continue? Benoît C.: the questions you need to get answers to are: how many vendors are going to implement this? and how many NMS are going to use this? Sam A.: 3 of them said yes George S.: Others said no. We still have to reach consensus. Benoît C.: to help in decision, knowing that this module extends another one you should try to know how many of have implemented the original module in read-write. ?: if implementers exist, then it would make sense to have the new module in read-write Sam A.: we do not have data models and so on in the charter of mpls. Is that going to be on charter? Ross Callon: this question does not stop us from thinking of work we should be doing. Sam A.: one of reason to push snmp, is that no other way (in mpls) of doing that. Benoît C.: we're trying to organise a hands-on session to train people to NetConf/YANG at next IETF meeting George S.: any other question for Benoît? any other question on the non-consensus regarding the TE writable MIB? Kireeti K.: I wrote a te-mib. Was read-only then became writable. considerable amount of work. We did not implemented the writable part Lou B.: I think it is better to ask who is using the writable module of a MIB than who has implemented it. draft-ankur-mpls-upstream-mapping-00 Mahesh Jethanandani, 10 min Himanshu Shah: you said you have an issue with data path Vs control. you still have implicit verification when going one hop further down and getting response back or not. George S. (hat off): lsp-ping is DP verification (it has connectivity and is sync with CP). because you get the packet back does not mean your DP and CP are in sync. Himanshu S.: same issue than with downstream map Kireeti K.: when doing downstream people are happy with ping/traceroute. The whole thing works. We can do upstream like presented, but it is not same paradigm. This is different than doing one hop away from egress, two hop away from egress and so on There are thus two options to do it. George S.: A third option: proxy-ping Kireeti K.: could do so when you reach egress when doing downstream George S.: state machine would be cleaner with proxy-ping Himanshu S.: other proposals are valid, but there is value in the current proposal as you can find the fault if DP LFIB is corrupted Sam A.: What do you do if you receive unknown tlv at the LSR? Mahesh J.: Good question. If you need the upmap you won't be able to validate the next node Sam A.: It means you thus need the whole network to support this TLV Mahesh J.: yes draft-ietf-karp-bfd-analysis-01 Mahesh Jethanandani, 10 min George S.: would it be sufficient to change the MyDiscriminator to bypass the 24days limit? Mahesh J.: yes by changing the mydiscriminator you could keep the same sequence number Greg Mirsky: Why is text struck out on slide 2? Mahesh J.: this is an error Greg M.: Do you see the need and use for authentication in mpls/pw as important as in ip? Mahesh J.: based on feedbacks, within one mpls domain, no real need for authentication. Greg M.: so limited to multi-hop bfd Kireeti K.: can be for single or multi hop between ASBR Kireeti K.: bfd typically kick-off by lsp-ping with discriminators exchange, so you could do an lsp-ping to change discriminator before you reach sequence limit. Also, regarding the figures you show, you are in fact saying that authentication is a DoS attack on yourself Mahesh J.: it is Shahram Davari: any number for non meticulous? Mahesh J.: numbers would scale pretty much the same. maybe enough for most customers. not for DoD. Curtis Villamizar: GTSM. Reason that you do not see any authentication deployments with BFD. Authentication makes the problem worse and this is something KARP as WG simply does not get George S.: what Curtis is saying is getting bad BFD packets and trying to authenticate them wipes you out Mahesh J.: authentication does not come for cheap. the fact that we did not put any crypto engine in the data-plane is a problem in itself Curtis V.: no, that's not the solution. turn on crypto engine and your power budget explodes. DDoS would be producing extreme amount of heat and would lead to shutting down the forwarding chip. Very effective DoS Mahesh J.: yes DoS gets worse with authentication, but DoS is a problem by itself with or without authentication Jeff Tantsura: [missed] Kireeti K.: we should bring back evil bit for mpls Curtis V.: What can we do for KARP to stop doing that? Karp needs to get a clue from OPS Area. This is a matter for the WG Chairs and ADs to get this straighten-up draft-chen-mpls-source-label-02 Mach Chen, 10 min George S.: segment routing work is going on. I think we should not adopt until that work moves along to avoid having multiple mechanisms. George S.: how many have read? (around 20) how many not read? (approximately the same) out of those that have read, how many liked the idea? (a bit less) and how many disliked? (much less than 20) George S.: somewhat evenly divided Mach C.: draft may be useful for segment routing but more general. no tight relationship with segment routing Himanshu S.: don't you have the source information in the oam packet anyway? Also, general purpose mechanism does not mean we should apply it everywhere. Greg M. (replying to Himanshu): the source label makes it easier to use oam in non tp networks, where you do not use source mep tlv also there is no requirement for the SL to be globally unique, can be unique within the LSP Himanshu S.: has to be unique per domain for a particular PE Greg M.: you can impose that but not mandatory George S.: so this is not for LDP, isn't it? Greg M.: yes you could George M.: no, I have no idea where does traffic come from when I receive it Shahram D.: do not like this idea. It is not 2 labels but 3 labels just to identify the source. Do inferred loss measurement. you do not need to do precise loss measurement Greg M.: using source mep tlv is better, is that it? Shahram D.: yes Luyuan Fang: I am open to technical discussion but what if someone does not use source routing? This should not impose source routing. George S.: Source routing or segment routing? Luyuan F. segment routing sorry. Mach C.: IGP advertisement is not a must for source label Xiaohu Xu: there is no different issue on stack depth than with entropy label George S.: add up to it Curtis V.: I don't like it but I think it does something useful. Applicable to anything that is mp2p. wrt Shahram concerns. Forwarding hardware does not have to look beyond the first label. This is oam, it will be sent off-path to something else that will parse the remaining labels. Mach C.: [missed] Stewart B.: if only for OAM, why not put an ip address in the oam payload, or a shim header? Mach C.: this is not only for OAM. Andy Malis: I know providers having already 4 active labels on the stack. Stack depth is not an argument anymore not to do things and this drat enables you to do stuff that you can not do otherwise. Kireeti K.: regarding deep label stack, yes we need to do more, but increasing the stack depth should not be considered lightly. George S.: modify my statement: we will discuss with our ADs on the next steps. Curtis V.: I thought it was only for OAM. If it is also for data packets then I really do not like it. Ross C.: Please continue discussion on the list draft-li-mpls-p2mp-te-alt-path-01 Zhenbin Li, 10 min Lou B., Curtis V., George S.: discuss on behaviour of nodes supporting or not the alternate TSPEC, on over-provisioning, preemption, and on and whether or not bandwidth is reserved in the data-plane. Lou B. looks like a new way for doing over-booking. Ross C.: Please continue discussion on the list draft-li-mpls-global-label-framework-01 Zhenbin Li, 10 min Curtis V.: trying to do mp2p with a global label Zhenbin L.: yes Curtis V.: you are loosing the characteristics of LDP Ali Sajassi: there was a similar presentation in L2VPN Looks like a solution looking for a problem. There are no issues in L2VPN. Current solutions are sufficient. Zhenbin L.: there are issues Ali S.: issues in the past. now solved with evpn and pbb-evpn. Ali S.: with respect to other areas that you mention, are there any issues currently that need global label? Zhenbin L.: several years ago there was no sdn and so separation of control and forwarding Ali S.: we already have solutions, so we do not have problems Stewart B.: I do not know how you make global labels work from a practical point of view. Idea came up in early discussion of segment routing but because of deployed hardware decided for an offset scheme enabling global numbers in the control plane but local labels So unless you plan on running an offset scheme, this won't work on existing hardware. Luyuan F.: I do not like the idea of global labels. Global IDs do not scale. And in SDN you do not want to set global ideas neither. Quintin Zhao: We are not getting rid of local labels, only using a range for global labels. Stewart B.: that is a fundamental architecture change Curtis V.: I see no advantage and see a lot of disadvantages so unless you can show some advantage, please put this away. draft-tsaad-mpls-p2mp-loose-path-reopt-00 Zafar Ali, 10 min Ross C.: who has read? fairly small number (4) Might want to take discussion on the list George S.: Do you need to allocate a bit? Zafar A.: yes George S.: what is the allocation policy? Lou: if going forward, I think it should be PS George (w/ chair hat on): was about to say the same thing Zafar A.: draft has already been through the process, can we skip the steps? George S.: draft is new, so we need to treat it same way as the other Curtis V.: operators are reluctant to reserve twice as much bandwidth as you need thus the success of FRR. So reserving 3 or 4 more ... Does anybody need this? Zafar A.: this is not about protection Adrian Farrel: you are asking codepoints out of standard track registry so we have to sort that out Also, look at IPR for 4736 as you build on it draft-cui-mpls-tp-mfp-use-case-and-requirements-01 Zhenlong Cui, 10 min 17:23 ?: is it for multiple simultaneous failures? Zhenlong C.: yes George S.: can backup path be shared? Zhenlong C.: yes George S.: then is m:n Sam A.: how different from m:n with n=1? m:n is super set so why this so why this is a separate requirement? Himanshu S.: indeed m:n is a super set, but m:n very difficult while m:1 doable Sam A.: we are talking requirements not solutions. What is specific in m:1 from a requirement point of view? Except for configuration there is no new requirements as I see. Also what do you mean when requiring shared mesh protection? You should also consider linear and ring topologies. Zhenlong C.: ok Himanshu S.: Sam has a good point, we should look into it. We are seing requirements for m:1 Rolf Winter: requirement is how to reduce cost associated with n>1 ?: a document exists on SMP Greg M.: encourage you to start with requirements and use-case as I am not familiar with such multiple failure scenarios Shahram D.: can m be anything? Zhenlong C.: yes Rolf W.: we do not want to limit m to 2. It might boil down to that operationally, but we do not want to limit that in the solution specification Himanshu S.: should look into what hardware and software can support Adrian F.: draft is quite short, it should be augmented to cover what has been talked about. Also should cover rate of failures. 1:1 as a way to simplify m:1. I like the simplicity of looking first as linear protection. George S.: continue on the list and flush out requirements. Too early for show of hands. draft-ietf-mpls-ldp-multi-topology-11 Quintin Zhao, 10 min George S.: we'll do a short 1-week WG LC * How to write a good RFC Experience feedback on document quality Adrian Farrel, 10 min Adrian presented recommendations for improving MPLS WG document quality. See slides for details.