MPLS: Progress in the IETF

1
MPLS Progress in the IETF

• Yakov Rekhter
• (yakov_at_cisco.com)

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
Possible MPLS Applications

• Traffic Engineering
• Virtual Private Networks (VPNs)
• VoIP

• Support for DiffServ/Qos
• Integration of ATM and IP
• etc...

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
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
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
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
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
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
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
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
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
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 ISPs point of view ?

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
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
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
Summary

• MPLS Multi-Purpose Label Switching
• IETF shouldnt 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