The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] updated wg minutes from Dallas
Working Group,
I've uopdated the minutes according to comments. At least
the comments I've seen.
The IETF schedule require me to upload the minutes toady.
If you have further comments send them asap.
/Loa
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.se
Minutes form MPLS WG meeting at the IEYF65 in Dallas ==================================================== Monday, March 20, 2006, 9.00 - 11.30 AM 1. Agenda bashing ----------------- Agenda adopted as presented. 2. Working group status ----------------------- As of this meeting we have a new Area Director for the Routing Area, Ross Callon. We welcome Ross and thanks Alex for the last for four years. A good MPLS status page could be found at: http://www1.tools.ietf.org/wg/mpls/ apart from document status it is possible to find also agendas and There are five new RFCs since the last meeting: RFC 4379 (LSP ping) RFC 4378 (OAM Framwork) RFC 4377 (OAM Requirements) RFC 4220 (TE Link MIB) RFC 4221 (Management Overview) There is also a non working group RFC: RFC 4381 (Informational) Title: Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) M. Behringer that should be interesting reading for the working group. The following documents are the in RFC-ed Queue: ------------------------------------------------ - draft-ietf-mpls-bgp-mpls-restart-05, for this draft there is a dependency to a document in the Inter Domain Routing (idr) working group. - draft-ietf-mpls-p2mp-sig-requirement-04, for this draft there is no obvious unresolved issues, and it should be published soon. The following documents are in IESG review: ------------------------------------------ The three drafts in the package to take LDP to Draft Standards: - draft-ietf-mpls-ldp-experience-00.txt - draft-ietf-mpls-ldp-survey2002-00.txt - draft-ietf-mpls-rfc3036bis-03.txt --------------------------------------- Alex reported from the IESG review. There are issues in that the IETF Standards Process (RFC 2999) says that a normative reference in a Draft Standard can't point to a document that is "only" a Proposed Standard. The LDP specification is dependent on the MPLS Architecture (RFC 3031) that is still Proposed Standard. The suggested remedy here is to included enough of the of the information that is reference directly in the LDP specification and then move the reference to Informational. Eric R said that this is a dumb idea. If you put pieces of one specification in another then you are creating problems Alex - we're not cut and pasting. For example if we look at place where label is distributed in LDP will treat this as an unsigned integer and then ref to the other doc. Eric pointed out that the standards process is broken if it can't handle this situation and if it is this broken we should revisit the decision to make LDP a Draft Standard, and just republish it as a Proposed Standard. If we put pieces (however small) into orther specifications we create a even more complicated than the one we have today, how to we update and change status on documents. The leason we've learnt is that the broken process generates lots of useless work. Alex said that we have a general problem with normative references that needs to be fixed, this is not limited to MPLS docs, it the IETF can't manage this we'll find ourselves in the situation we were 5-6 years ago where MPLS docs were in the RFC-Iditors queue for years as none of them could go ahead beacuse of very "meshy" references. We need to find a way to decouple references. - draft-ietf-mpls-ecmp-bcp-02.txt --------------------------------- This draft is also in IESG evaluation. There is a "discuss" in the review that has not been solved. George will meet with Margaret Wasserman to try to solve the problem this week. As soon as the discuss is resovled a new draft with be published, - draft-ietf-mpls-nodeid-subobject-07.txt ----------------------------------------- This document has been approved by the IESG and announced, but has not yet shown up in the RFC-Editors queue. Working group drafts: --------------------- The draft that will be on the agenda later is not reiterated here. draft-ietf-mpls-icmp-04 ----------------------- This drafts has a dependency on a draft progressed in the Internet Area, that draft will be on the Internet Area agenda this week. Ron will be back with further information as soon as we have the outcome of the discussion in Internet Area. draft-ietf-mpls-lsr-self-test-06 -------------------------------- The LSP Ping has been approved, so the LSR Self Test is now ready to be sent to the IESG for review. draft-ietf-mpls-multicast-encaps-00 ----------------------------------- No news this time draft-ietf-mpls-over-l2tpv3-01 ------------------------------ The draft has been republished and is ready for Working Group Last call. draft-ietf-mpls-p2mp-lsp-ping-00 -------------------------------- This draft has been waiting on multicast LDP to stabilize. The issue has been whether to put TE and LDP in the same draft or not. Authors want to discuss with the multicast LDP authors during this week to reach an agreement. draft-ietf-mpls-p2mp-oam-reqs-01 -------------------------------- There were useful comments on list on the earlier draft, it has been respun. The authors think it is ready for working last call. draft-ietf-mpls-soft-preemption-07 ---------------------------------- This draft has a dependency on a yet unpublished BCP, J-P has promised to start the process to get this BCP moving. draft-ietf-mpls-upstream-label-00 --------------------------------- No news. "Un-published" working group drafts ---------------------------------- draft-raggarwa-mpls-ldp-upstream-00 has been accepted as a working group draft and will be published after the IETF meeting. Other than that - no news. "Dated draft" working group drafts ---------------------------------- draft-ietf-mpls-fastreroute-mib-04 has expired, Tom has taken the initiative to republish and finalize this draft. 3. MPLS traffic engineering --------------------------- draft-vasseur-mpls-number-0-bw-te-lsps-00 ----------------------------------------- The problem addressed in this draft is balancing trafffic across multiple ECMPs. Currently non-zero b/w LSPs balance OK the 0 b/w ones don't. To re-optimise one need to know how many 0 b/w LSPs one have per link. Currently there is no knowledge of this in OSPF-TE or ISIS-TE so one can't just run a CSPF. Proposal is a new sub-TLV that just advertises the number of zero-b/w LSPs on each link. There is no changes in the flooding procedure involved and no IGP scaling impact. This is a very simple solution, to a very real problem. Working group chairs pointed out that this proposes changes to OSPF and ISIS. It should be taken to those WGs after we agreed that it is a requirement? draft-ietf-mpls-explicit-resource-control-bundle-01 --------------------------------------------------- No one of the authors were present. This item was deferred. draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01 ------------------------------------------------- Kohei Shiomoto This draft is intended for the CCAMP working group presented here for information and to solicit feedback. The draft discusses migration requirements, models, and scenarios for a migration from an MPLS-TE to an GMPLS control plane. For the migration period four interworking scenarios has been identified: 1) MPLS->GMPLS->MPLS 2) GMPLS->MPLS-GMPLS 3) GMPLS->MPLS 4) MPLS->GMPLS In the first two cases the ingress and egress LSRs are in the same technology domain. There are two major areas that need more work - signalling and routing. To achieve the migration goal we need to pay special attention to differences how these are treated in the MPLS and GMPLS domain. The problems are mostly identified and the next step is to is to figure out which solution directions we should take. Feedback and comments from the MPLS working group is appreciated. draft-yasukawa-mpls-scaling-analysis-00 draft-yasukawa-mpls-mp2p-rsvpte-00 --------------------------------------- Seisho The drafts discusses MPLS scaling issues given larger MPLS P2P networks, if a large number of PEs need to be fully meshed this generates a huge number of LSPs in the core. The draft looks at different scaling limitations, e.g. memory, processing and management. Memory is not seen as a real problem, the processing issues might be for e.g. soft-state, protocols, the impact of a large number of LSPs on Network Management Systems (NMS) could be drastic. The draft discusses three possible strategies to address these scaling issues, P2P tunnels in the core, LSP hierarchy and MP2P LSPs. P2P tunnels gives god scaling in the core, LSP hierarchy is most effective towards the edge, while MP2P LSPs is effective near the egress, but have no impact near the ingress. Next step will be continued analysis of scaling issues, to determine real network sizes and limitations. A requirements draft will be written, and work with implementers is planned. JP commented that this is very interesting and promising as far as it goes. However there are issus that in to be addressed. These issues are e.g. sizing of core tunnels, fast re-route and protection of hierachical LSps will reduce the benefits. JP offered to work with the authors to cover these issues. This draft is intended to become an Informational RFC. 4. MPLS p2MP ------------ P2MP LDP requirements draft-leroux-mpls-mp-ldp-reqs-03 -------------------------------- Jean-Louis Changes since previous version - solution oriented requirements and text that said that a multicast routing prtocol should not be required been removed. A "complexity requirement" has been added saying that additional routing protocol should not be required in the core. Requirements on avoiding replication on LAN interfaces has been clarified. A branch LSR must be able to send one copy on a LAN to reach multiple downstream LSRs. It must be possible to select a single upstream LSR on a LAN for one P2MP LSP and it shall be possible to load balance between candidate upstream LSRs. The draft is now quite stable, but needs working group feedback. There are some comments (mostly editorial) that will be included in the next version. There is a growing support to make this a working group document, working group chairs will take this to the mailing list. draft-ietf-mpls-ldp-p2mp-00 --------------------------- Ice This draft is the outcome of merging to earlier drafts from Ina and Ice. It is now a working group document. Changes since the earlier individual version - references to the upstream label allocation drafts has been added. There is some future work needed: - resolve issues of ECMP upstream LSR selection - minimize packet loss during upstream LSR change (make before break?) draft-ietf-mpls-rsvp-te-p2mp-03 ------------------------------- Dimitri Some point has been discussed over the last couple of weeks, it is time to wrap up. - document how to protect against branch failure, there are three alternatives a. include the simple cases in the current draft and leave the rest to another draft b. take the whole issue to a separate draft c. postpone publication until we have solved this issue No one is arguing for option c, and we seems to be converging on option b. There is also a proposed a clean-up of the terminology. Version 4 will be ready to publish end of April and should be the draft we take to working group last call. Reroute Extensions to LDP for P2MP LSP draft-liu-mpls-ldp-p2mp-reroute-00.txt -------------------------------------- Shuying Liu The goal of this draft is to reduce disruption and duplication during rerouting. The rerouting mechanism in draft-ietf-mpls-ldp-p2mp has issues in terms of LSR load, traffic disruption and scaling. A new mechanism which reduces disruption time and data duplication is proposed. Working group chairs pointed out that there is already a working group document that potentially will address these issues (draft-ietf-mpls-ldp-p2mp-00). The two group aóf authors should discuss and see if it is possible to merge these ideas into the working group documents. 7. T-MPLS; report from the IETF liaison to ITU-T SG15 ----------------------------------------------------- Transport MPLS Adrian Adrian very carefully pointed out that he was reporting on an activity within the ITU-T Q12/15 for information. "Don't shot the messenger". He also did a quick ITU-T introduction and discussed the relevant Study Groups (SG). ITU-T is very contribution and process driven. SG-13 is NGN, SG-15 is access network transport and optical techologies. T-MPLS is not optical, but it is access network transport. Question 12 in SG-15 (Q12/15) owns T-MPLS. A Question is the ITU-T rough equivalent to an IETF working group. The T-MPLS activity has been going more than a year. But so far no information on this has been sent to IETF and/or the MPLS working group. ITU-T and Q12/15 have consented recommendations (roughly equvialent to and RFC) for an T-MPLS architecture (G.8110.1 - Feb 06) and Interfraces for T-mPLS hierarchy (G8112). The T-MPLS is build on MPLS, but it is not obvious that it is directly compatible. It introduces a formal structure (e.g. UNI and NNI), some functional restrictions as compared to MPLS (e.g. no PHP, no MP2P/LDP, no ECMP). All LSPs are uni-directional, bi-directional LSPs are created by associating two uni-diretional LSPs, i.e. not GMPLS compatible. OAM are according to Y.1711, i.e. not compatible with LSP ping. Protection switching and survivability is Y.1720. P2MP is for furhter study. The control plane is not decided, but ASON, MPLS-TE, GMPLS, LDP++ are still discussed, though it is not clear what LDP++ really is. Anyway it is an indication that the LDP base specification is not sufficient. One criticial issue from an MPLS point of view is that labels 16-31 have been chopped out as reserved lables for future study. If this happens all existing MPLS HW will be incompatible with T-MPLS. Next steps: 1) get a copy (limited free download allowed and MLPS WG may liase to ITU-T to get a copy). 2) debate (with care!) Remember these are from another body with their own views and they have put *serious* thought into it. therefore raise Qs, don't tell ITU-T what to do. 3) show (somehow) that existing protocols meet the needs (if they do). Eric R: This might be one of the few cases where it may be appropriate to shoot the messenger! IETF doesn't want to get involved in this attempt to do Frame-based ATM. It would be best not to engage at all. It would be useful to figure out whether T-MPLS is incompatible with MPLS in data plane, and if so then send a liason to ITU-T asking them to make it clear that T-MPLS is not MPLS. Adrian pointed out that if ITU-T Q12/15 or anone else decide to extend or tweak our protocols then we need to either be involved or to let them do it. Loa: In the particular case of ITU-T there is an agreement between them and IETF to exchange certain type of information. Q12/15 has failed to do this in this case. Dimirti - we already have several flavours of control plane, we don't want another. Kireeti - It is very annoying that this has even got this far. We have a GMPLS/MPLS change process. The idea was to do this co-operatively with ITU-T people. Now they've got a set of requirements that became a recommendation without working with the proper IETF Working Groups. Mandating no PHP is funky, mandating no merging is really funky. Can't just go round messing with SIP and call it SIP. So can't go messing with MPLS and call it MPLS. Yakov - it is interesting that thee same discussion can say "no merging" and "LDP" (which is MP2P protocol). Italo (Editor of G.8110.1) - we are willing to discuss. T-MPLS is defined to be a sub-set of MPLS. Idea was not to deviate from the current standard. George - as chair you need either to liase with us (if you want to use the name "MPLS") or go off and name/do your own thing... if it's called "T-MPLS" then its name is a little close to MPLS so it would be nice to agree with us. Is "consented" final? Editor - no, you can do last call comments after consented. Last call is end of this month. Yakov - Question to WG and its chair. If you take the MPLS data plane as is and use PNNI as the control plane then what would you call it? Answering that question will help us deal with this Q. George - "We could do that, but that would be wrong". Loa - The working group chairs will send a liaison to SG15 and point out the failure to communicate and require that the T-MPLS documents are liaised to the MPLS working group. 8. RSVP-TE extensions --------------------- draft-xu-mpls-rsvp-te-bidirection-00 ------------------------------------ Xiaohu Xu By the binding of two unidirectional RSVP-TE tunnels between a pair of LSRs, a bidirectional RSVP-E tunnel could be formed. The bidirectional RSVP-TE tunnel can be used e.g. to establish L3VPN with virtual router technology. It was decided to take this discussion to the working group mailing- list. 9. End of meeting _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|