2.4 Routing Area

Current Meeting Report

Many thanks to David Allen for taking thse minutes.

The following are the notes taken at the routing area meeting 00/08/02.
Flippancy is verbatim (no editorial embellishment ;-)

Routing Area Meeting
chairs Dave Oran, Rob Coltun
scribe, Dave Allan, dallan@nortelnetworks.com

Control plane work organizational goals
- divide the work in a way that clearly maintains independence among the control plane signalling protocols, the routine protocols, the encapsulation mechanisms.
- expeditiously moves new work on restoration, link characterization disjoint path computation, forward in a way that is generic across technologies.
- goal: provide a home for "foo-over-MPLS" sort of things.
- ensure IPO is focused on optical specific issues.
- encap, MIBs, optical specific requirements

- initiate a group in the routing area to undertake the generalized parts of the control plane with specific milestones for:
- restoration
- link management
- and diversity routing as a starting point
- this could be a routing area WG or one or more new WGs
- work effort will also consider "foo over MPLS"


Discussion w.r.t Optical UNI and applicability to IPO group or elsewhere, not resolved.

Concerns about both the charter, and delays as a result of redistributing the work.

Dave O: Please take inputs to the list. Will figure out what to do with this in a couple of weeks.


MPLS uber alles is where the routing area is sitting at the moment. The proposal is to define an encap to carry MPLS in IP. The intent is to extend the functionality of MPLS tunneling. Currently one can define a tunnel and exchange information, compress headers etc across an MPLS core. So everything is done, we just need to be able to carry it over an IP packet. So we need a protocol number and a little bit of usage considerations. This is the most important part of the draft. Most readers assume we are bridging islands of MPLS across an IP core. Not the original motivation. Not really suitable as a general encap. Normally you'd want to move towards an MPLS core. Also if you have GRE you can do those tunnels. Also RSVP may need to be put in IP over IP (make router alert visible).

Request: Does the IETF want to have a single way to encapsulate MPLS in IP. And which group should do it?

Q: Not impolite naïve question. MPLS was defined because some things could not be done in IP. If you are using IP, then why MPLS.
A: When you define something of sufficient utility, its usefulness grows. You can extend the applicability (VPN etc.) of stuff running over MPLS.
Eric: This is not "foo over MPLS", it is "MPLS over foo" so it belongs in the MPLS working group.


Eric: Don't know what Yakov had in mind, but it almost isn't worth a slide. We are now worried that there will be a war over the "one true way" to carry MPLS over IP. MPLS in IP does save a word, but if you already have a GRE tunnel....
Some discussion on the evolution of GRE.


L2 Circuit transport over MPLS proposal.

Requirements, trying to accomplish lots of things. Transport of legacy L2 protocols. (e.g. AAL5, FR, Ethernet). No IWF. Use MPLS QoS mechanisms. Use 2 level label stack for scalability. Customer tunnels only seen by edge devices.

- two label stack, VC label and IGP label. Want to distribute from edge to edge using LDP. Want to do sequencing and take care of little quirks. Need a protocol specific header. Plus some semantic translation, e.g. mapping ATM CLP bits into EXP bits so we can do intelligent things.

VC Labels:
This is not IP so we need a means of mapping this into LDP, so we came up with the VC FEC TLV. Static mapping is possible. Circuit status is signalled using label mapping.

IGP Labels:
Can be setup by current methods.
VC FEC TLV, want to do some compression of withdrawls like to converge on a single message. VC-ID identifies the circuit. Group ID can identify the port or the virtual tunnel. VC-ID type (FR, ATM, Ethernet, HDLC etc.) Control word contains sequence number. Length is either 0 or the length. If length is < 256 so that for media that requires padding, we can recover the original packet length.

Next steps:

Merge this with draft-malis-sonet-ces-mpls-00?

A: The authors agree to merge regardless of what WG this ends up in.
Q: As far as FR is concerned, what is the assumption of QoS for FR. It will not be able to react to frame drops etc.
A: You still have discard eligibility so if MPLS encounters congestion intelligent things can be done.
Q: the simplest thing would be to do what FR switches do, FECN and BECN.
Andy: Simplest thing would be at the de-encap edge to examine the ECN and modify the frame relay traffic accordingly.
Q: What about OAM.
A: We loop them, if one end goes down, we stop looping them. Effect is the same as one big ATM circuit.
Neil: AIS and LB not covered, CC and PM OK. Don't understand how you can do this. Speaking as an operator, I'd like to get rid of a few layers. I want MPLS to take on the role. We can put a SONET VC4 in MPLS if we like, but it doesn't make sense. Need a reference model of how many times you can go in and out of these things, it just won't work.
Q: Addressing Neil, it's the same as IP in IP.
Neil: Customers with applications on ATM and FR have certain expectations, server layer defects propagate upwards. Client layer may not know what impairments they are inheriting.

Discussion to move off line.

Q: What about directionality. What about 802 traffic.
A: Meant to transport 802.1q VLANs, multipoint is a different problem. This is p2p.


Andy Malis/Vivace networks

Scope: SONET STS-1 SPE, and STS-Nc (n=3,12,48). SDH VC-4/4c/16c.

Open issues:

Q: How to extend timing for CEM?


SONET over IP/Jim Boyle-Craig White

Written as an encap draft, it's really a funcitonality draft. Want to carry SONET over MPLS for a number of reasons (hopefully true).

Difference: Don't need to translate signal slips across the network.

Approach: (see slides)

Q: where can we discuss this stuff in the IETF.
Rob: General comment, this work is going to be done somewhere at some industry forum. People who run networks get high priority here. What do people think. Should this be taken on?
Q: I'm an IP bigot, routing fixed problems in half a minute. Now we are going to put TDM on an IP network. TDM has quality problems of it's own. What kind of service is IP going to provide. If you want we to build a non-reordering 50msec IP network, we've missed the cost effectiveness target.
A: I'm an IP bigot in a transmission company. IP is approaching SONET. SONET is hard to manage and add capacity. W.r.t 50 msec vs. 30 sec. In western U.S. SONET rings do not do 50 msec. 300 msec IP would be competitive.
Rajesh: industry moving towards everything over IP. (groans). Can IP really deliver. We are discussing the IP of tomorrow. By the time we are done, IP may deliver 50msec. Question, should to be done at the application layer
over RTP. This is a carrier or service provider issue. Leave out the applications.
Eric: pragmatic problem, service providers trying to transition their core. They don't need everything, just to move frames. If someone else does this, the spec will be overly comprehensive (300 pages).
A: A cross encap WG would be a good thing.
Observation: making routing protocols work two orders of magnitude faster would be required.
Bilel: Do not have all the requirements, but are collecting them from service providers. This should be one of the working groups mentioned by Dave.
Liam: Not clear if it should be done here or ATMF or T1X1. Encap is the easy part. Understanding what to do with delay, OAM cells etc. Work may start here, but needs to feed into complementry efforts in other forums.
Worster: Its about migration. An old RFC warned of the dangers of mutual encapsulation.
Dave O: Can we take the timing question to the mailing list.
Q: Ultimately you need a physical layer, are you not carrying SONET over IP ultimately over SONET.
A: it uses all those extra bits.
Q: Vendors are going to do this with or without this. We can do this interoperably or go here again more painfully in about a year.
Curtis: There will be informational I-Ds, we did it imperfectly this way. Foo over label switching makes an interesting acronym.


Ben Mack-Crane, Vishal Sharma
Many contributors.

Goals: provide a framework, unify terminology.

Models: protection switching (pre-planned), reroute (post failure), lots of variations.



Multi company draft.

Goal, use MPLS for carrier class VoIP transport.

Example MPLS tie line: RSVP admission control, aggregation, signalling for compression and muxing. Backup TE tunnel for fast re-route.

There is already a first draft of the protocol gap list.

We'd like to propose that this I-D is adopted by the new WG.


L2 Circuit Transport Over MPLS Proposal