IETF 54 MPLS WG Notes Thursday July 12. 9 - 11.30 AM Chair - Loa Andersson (George Swallow not in attendance). Note Takers - David Allan, Eric Gray Loa: Agenda bashing -------------- - process reminders/blue sheets - LDP MTU draft off the agenda - No further comments on the agenda Loa: LDP (RFC 3036) to draft standard (status) ---------------------------------------------------------------------- Loa talked about the need to collect implementation information on LDP for taking it to Draft Standard. It is still not clear how many other RFCs will be affected, encap and LDP draft, maybe also architecture. This is because of normative references. A survey form is developed and will be published on the list in a few weeks, together with instructions on how to respond. Asked to include an anonymity option. Scot Bradner will act as anonymizer. Results will be published as an I-D. One intention will be to simplify LDP, so unimplemented stuff will be removed when LDP is moved to draft standard. Scott Bradner AD: Current state of the issues in the mpls oam discussion and the ITU-T liaison. ---------------------------------------------------------------------- The background is that we have an I-D, by Hiroshi Ohta, requesting a reserved label to be used by ITU-T, for OAM. At the last meeting the discussion concerned changes to IETF protocols that would result. As a result a liaison was sent for clarification, asking if they were operatingunder the assumption that they would be requesting changes. The draft is called: "Use of a reserved label value defined in RFC 3032 for MPLS OAM functions" Liaison response: Hiroshi Ohta (SG13 Rapporteur, slides included) Hiroshi Ohta presented a report on ITU-T's response to IETF's liaison on MPLS OAM. He stated that they do not expect to impact IETF protocols and minimal impact on implementations. Y.1711 cannot work without the reserved label - therefore, they request that IANA assign a reserved label. Discussion ---------- Rahul Aggarwal: The statement of no impact on forwarding plane is inaccurate, on egress LSRs there will be an impact. Kireeti: If we allocate this label, will the ITU use this label 'efficiently', in other words, will there be other requests. Scott: The ITU is finding that IETF protocols are popular, so they want to use them. He gave an example of the process using SIP. The IETF decides that protocols developed by IETF need to be reviewed by IETF when extensions are being proposed. Kireeti: there are two concerns, one is the IETF process (which is good) band the other is how far does this go? Do they need to go through the RFC process. Scott: This may be dealt with in many ways, however we hope that the cooperative approach will work. Scott asked the sense of the room: We have an I-D seeking assignment, we've interacted to find out answers to questions we've asked. I think this is a good thing, both cooperatively and for the good of the protocol. MPLS is being used in a number of environments, and the usage assumptions are different depending on the carrier. We need to support the IP carrier, but that is not all of them. In that context we should be open to the use of our protocols in other environments. For MPLS to be seen as useful in trad telco environments it needs this stuff. Hummm (a few raised hands :)) showed a consensus for RFC publishing the draft and issuing the label. Scott Bradner: rsvp-te vs. cr-ldp, initiating a discussion ---------------------------------------------------------------------- In the implementation survey for GMPLS, there was lots of RSVP and little CR-LDP. Concern in ISEG on multiple standards track ways of doing something is confusing to the market place. Don't need to visit the history. Don't think we need to stop publishing CR-LDP, but should they be informational or standards track. Discussion: ---------- Loa: The intent of having this agenda item is to initiate the discussion, not arrive at a conclusion at this meeting. Bilel Jamoussi: Comment on the survey. Did not state the objective or indicate how it was going to be used. Not scientific by any means. More importantly GMPLS is a new thing, carriers are still debating the architectures. Think the discussion is premature. There are today several networks running CR-LDP in a packet environment. Bert: Purpose of survey was to seek an implementation report before approving GMPLS. This was an artifact of the survey not the intent. I don't think discussion is premature, a decision may be. Folks can still implement informational. Within one org you would normally try to go for one standard. Kireeti: I wear several hats. CCAMP chair, twice as many protocol extensions because of two protocols. Have to write two sets of drafts as an author. Have to read twice as many. As a vendor I do not care, and do not implement it. Impact on IETF is twice as much material. Luca Martini: as a service provider, we found RSVP predominantly deployed and implemented. Pushed by a particular vendor for an obscure reason. We should shift CR-LDP to informational. Ron Bonica: Like to second what Luca said. IETF produces too much technology to do a good job. Lets prune. Chris Liljenstolpe: Third what Luca said. Osama Aboul-Magd: From transport POV, the market is really slow so deployment is pretty much nonexistent. This is not an indicator. Joel Halpern: Helped work on CR-LDP, technically prefer it. That's irrelevant, its not about what is technically better, RSVP won the fight. Bilel: Agree on one application. Not necessarily so for optical transport. For packet TE, RSVP has one the fight. In optical it is premature. So Packet TE it is overwhelmingly RSVP, but GMPLS it is premature. Folks are building on the CR-LDP. There are other examples of multiple protocols. Bert: Past potential mistakes are not necessarily an indication of what we should do in the future. In this case one far outweighs the other. Chippy: We don't support it because we have no customer demand. Ludo Practico: We support both and get interest in both. Discussion to move to the mailing list. Loa: Confine it to the MPLS list, but we'll send mail to the other sub-ip list informing them about the discussion. Bert Wijnen Status and issues with the mpls mibs ---------------------------------------------------------------------- We have lots of MPLS MIBs. Although separately they looks OK, there was a lot of overlaps (TCs and the like, some conflicting). Shows authors not working together, and no cross review of how they play together. No discontinuity timers for counters, or how MIBs relate to each other. etc. etc. Several issues, including inconsistencies and duplicated uses. Also, there are uses defined that are not consistent with common usage elsewhere. Some MIBs have already become RFCs and others have been held up in queue for corrections. There is a draft that attempt to capture the relationships between various MIBs, but this does not do quite enough. Also, there are some MIBs that are fairly 'all-inclusive' and it is not clear that this is always a good thing. Also, there are differences in the 'tolerance' levels for various MIB compilers and this results in MIBs that do not compile using some MIB compilers. We would also like to see better communications between various MIB development efforts. We would also like to see who is implementing which MIBs. Finally, people should get help for MIBs at mibs@ops.ietf.org or by asking the SNMP/MIB advisor for the working group. If there is no SNMP/MIB advisor, get one. Summary: - Main concerns/worries: o How do Label Distribution Protocols, SNMP, Manual config, GSMP interact and make sure they do not step on each others toes?? o How are assignments under mplsMIB controlled? o Who is implementing all these Mibs? o How is the impact on follow up (G)MPLS MIBs? - Status/Action plan o Authors have answered a lot of comments and supposedly know what needs to be fixed. o Authors revising MIBs to address comments. Sofar I have received a new TC MIB, need revisions of all otehr MIBs o Then will need to re-review (MIB-Doctor) o I want the WG to re-review as well and make sure that you all agree, before it gets approved Marcus: We have actually implemented some MIBs only partially. Bert: The correct way to work through this is to talk about these issues on the public mailing list so that everyone can benefit from understanding the issues and answers. Kireeti: Asked if Marcus had tried the TE-WG MIB. Marcus Brunner: I was actually referring to the LSR MIB. Vach Kompella: I've had issues with the LDP MIB and we've also implemented a proprietary MIB that supports a subset of the MIB. Bert: The LSR MIB is in IESG review at this time. We had reports that people are implementing the LDP MIB. Loa: My impression is that the MIBs have become complicated and uncoordinated. My feeling that we still need to think about what to do next. It is at least clear that enough changes have occurred since the last set of last calls that once we see the updated MIBs we will need another round of last calls. Andy Malis Status of LDP restart and LDP fault tolerance drafts Fault Tolerance for LDP and CR-LDP Graceful Restart Mechanism for LDP ---------------------------------------------------------------------- Andy: The latest status is that the LDP FT draft was successfully merged with the Smith (check-pointing) draft. The LDP Restart draft actually has a different applicability with very little overlap. The last call has been completed, George Swallow has proposed some changes, some minor editing has to be done and then the draft should go to the IESG. Sven van den Bosch Further considerations for Forwarding Adjacency LSPs ---------------------------------------------------------------------- Sven van den Bosch : This is version one of the document, related to LSP hierarchy 07 WG draft, since there might be some interdepencies betseen the resource classes and the use of backup LSPs without any assigned bandwidth, The issues addressed is complex resources classes and a new sub-class of TLVs proposed. Alternatively it could be possible to approach the IS-IS and OSPF wg's and suggest that they define extensions to the protocols. Amir Hermelin: Is it the the goal of this draft is to be merged into other work. Sven: I feel it is useful to keep the draft as an overview of outstanding issues but that any eventual resolution of any of the issues could be merged with other work. Kireeti: Not sure that all cases of complex resource classes can be represented. Sven: I'm aware that there is at least one case that his proposal does not cover, but also feels that there is a real need to solve a subset of the problem space that his proposal does address. Although the solution does not work in this particular case, an operator will always know (by virtue of its resource class specification policy) whether or not it is safe to use the proposed solution. Loa: Take this back to the list and make a decision once all the implications are clear. B Jensen:(University of Wisconsin) General Summary of Interoperability Testing Results and Experiences ---------------------------------------------------------------------- There are interoperability efforts from several organizatios e.g. UNH, AIL, MPLS Forum etc. There has been private tests in April, NI in May, and then Supercom. White paper will available from MPLS forum. The Draft is key findings from April, test configuration are shown in the slides. IP transport, plus L2 and L3 VPN apps (2547/Martini Ethernet), POS and GigE plus some ATM. Has been tested. Issues found: OSPF TE is not universally supported even though required for TE LSPs Vendor implementations only support a single distribution mode (DU/DoD) Not all RSVP-TE implementations support both FF and SE reservation styles Inconsistent use of IP addresses in ERO RESV_CONFIRM is not universally supported Explicit NULL label is not universally supported Discussion: Amir said that he was surprised that the presentation was being given before there was a white paper presented and said that the issue with explicit NULL labels is essentially because of a misunderstanding of the standard. Satoru Matsoshima asked about DU implementations that do not respond to requests for Labels. Rahul said that their implementation simply supports all of the possible ERO IP address usages. Amir commented on the ERO issue, saying this is critical. Loa said that the discussion should be continued on the list, thanked him for the report. J-P Vasseur MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection ---------------------------------------------------------------------- P Vasseur: The draft addresses the charter item dealing with recovery mechanisms and focus on bandwidth protection issues. The draft proposes two basic approaches - centralized and distributed. It was pointed out that a Naive approach - using CSPF to setup backup paths - has two key problems: it cannot protect bandwidth efficiently as it is difficult to share bandwidth between independent failures, and it is possible that no solutioncan be found even though it can be shown that one must exist (as a result of timing). Examples of real life scenarios were given, in which bandwidth protection is needed. Bandwidth protection is needed for some traffic in some networks and input on the draft is solicited. Sven: What is the impact of using backup LSPs without bandwidth reservation on the performance of the constraint-based routing algorithm (given that it is based on unreserved bandwidth advertisements)? JP Vasseur, Anna Charny: You would need to split the available bandwidth between bandwidth available for LSPs without BW reservation and LSPs with BW reservation. Loa suggested that comments on this work should be taken to the list. Seisho Yasukawa Extended RSVP-TE for Multicast LSP Tunnels ---------------------------------------------------------------------- Seisho Yasukawa: The draft is about potential extensions for RSVP-TE for multicast LSPs. One of the things we propose in the draft is a grafting mechanism. A mechanism like this is needed e.g. for a VPLS service. It is appropriate that the multicast specifications should be discussed in the working group because the charter already includes work on the framework for multicast. Proposes that the WG should accept this draft as a WG draft. Saha asked if the draft required a multicast routing protocol, answer was that no multicast protocol is needed, but a function needed to determine the the multicast tree. Loa: This should be taken to the list. We are currently not prepared to take on new wg documents for multicast, we need a discussion to scope the multicast work within the mpls wg before we do that. That discussion should also be taken onto the list. H.Hummel: "Hierarchical LSP" "O(n**2) investigations". ---------------------------------------------------------------------- Heinrich: The motivation for this work is to eliminate the n**2 problem via partial mesh of elementary tunnels. We have done tests and simulations to determine precise values for scalability associated with the use of hierarchical LSPs. Hierarchal LSPs is in scope for the charter by implication because of the existence of the label stack. Discussion deferred to list due to time constraints. Loa: WG and document status, Questions ---------------------------------------------------------------------- 19 RFCs, latest is RFC 3270 on diff-serv. Multicast framework on the RFC-ed queue. 19 WG docs. 18 individual submissions. The issue here is that the individual submission are so numerous and diverge so much. This is a mature WG, and should be more focused. The wg documents: 5 under MIB doctor treatment. 6 documents under chair/AD (pre-IESG) review before going to IESG. 4 in WG last call. (FT completed just before meeting). 4 work in progress (incomplete). Meeting ended 11.30 AM.