1. 1 MPLS: Progress in the IETF Yakov Rekhter (yakov@cisco.com)

2. 2 Disclaimer Not an ISP perspective Not a vendor perspective My personal perspective: – not on MPLS in general – just on the MPLS effort within the IETF

3. 3 Possible MPLS Applications Traffic Engineering Virtual Private Networks (VPNs) VoIP Support for DiffServ/Qos Integration of ATM and IP etc...

4. 4 Possible MPLS Applications (cont.) Question 1: are these applications worth deploying ? Question 2: is it appropriate to use an MPLS-based solution ? Question 3: are these questions within the scope of the IETF ? – probably not – let the best applications win

5. 5 MPLS Architecture 101 Labels are bound to routes Forwarding component: – uses label information carried in a packet and label binding information maintained by a router to forward the packet Control component: – responsible for establishment and maintenance of correct label binding information among routers

6. 6 “One” or “More than One” ? Diverse applications will require functionally diverse procedures for maintaining the Forwarding Component Could all this functionality be implemented within a single protocol ? – probably Should all this functionality be implemented within a single protocol ? – opinions differ

7. 7 “One” or “More than One” ? Should the MPLS WG work on “only one” solution ? – yes, if there are people that want to work on this Should the MPLS WG work on “more than one” solution – yes, if there are people that want to work on this Should the MPLS WG decide on “one” vs “more than one” ? – probably not

8. 8 RSVP for Traffic Engineering What is needed: – ability to establish and maintain a Label Switched Path along an explicit route – ability to reserve resources when establishing a Label Switched Path Interdependent, not independent tasks – benefit from consolidation

9. 9 Use of RSVP for Traffic Engineering (cont.) RFC2209: – “provides a general facility for creating and maintaining distributed reservation state across a mesh of multicast and unicast delivery paths” Traffic Engineering: – use as a general facility for creating and maintaining distributed forwarding & reservation state across a mesh of delivery paths

10. 10 Use of RSVP for Traffic Engineering (cont.) RFC2209: – “transfers and manipulates QoS control parameters as opaque data, passing them to the appropriate traffic control module for interpretation” Traffic Engineering: – transfer and manipulate Traffic Engineering control parameters as opaque data, passing them to the appropriate module for interpretation

11. 11 RSVP Usage in the Context of Traffic Engineering Differs from the “RSVP Classic”: – state applies to aggregated (macro) flows (i.e. a traffic trunk), rather than to a single (micro) flow – paths are not bound by destination-based routing – RSVP sessions are used between routers, not hosts

12. 12 RSVP and scalability (RFC2208) “the resource requirements for running RSVP on a router increases proportionally with the number of separate sessions” –one traffic trunk aggregate many micro flows “supporting numerous small reservations on a high-bandwidth link may easily overtax the routers and is inadvisable” – n/a in the context of traffic engineering - trunks aggregate multiple flows

13. 13 Use of RSVP for Traffic Engineering (cont.) RSVP: subsetting + extending – extensions for traffic engineering – extensions to improve scalability Can we still call it “RSVP” ? – why does it matter from an ISP’s point of view ?

14. 14 Traffic Engineering: RSVP vs LDP Could Traffic Engineering be implemented with LDP ? – probably yes Could Traffic Engineering be implemented with RSVP ? – yes Should Traffic Engineering be implemented with LDP or with RSVP ? – opinions differ

15. 15 Traffic Engineering: RSVP vs LDP (cont.) Should the MPLS WG decide on RSVP vs LDP for Traffic Engineering ? – opinions differ Note: please remember the IETF past experience handling “multiple choice”

16. 16 Time to market Going through the IETF standards process takes longer and longer… – speeding up the IETF process may take even longer… Internet Draft is as good as an RFC for the purpose of interoperable multi-vendor implementations ISPs and vendors should focus more on openness + interoperability, less on the IETF formal status

17. 17 Summary MPLS = Multi-Purpose Label Switching IETF shouldn’t pretend to play the role of market forces IETF should focus on developing standards-based solutions ISPs should place more emphasis on timeliness, less fixation on the formal IETF status