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, firstname.lastname@example.org
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:
- 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.
(SCRIBES NOTE: THIS MEANS THE DISPOSITION OF MOST ITEMS PRESENTED IS TBD, HENCE NO RESOLUTION IS CAPTURED IN THESE NOTES, SOME DISCUSSION IS CAPTURED).
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.
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.
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.
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.
- Include both synchronous and adpative clocking modes. Targeted to OC192.
- TDM data stream is segmented into fixed size packets (up to 1023 octets).
- Each packet is label stack followed by 323 bit TDM header.
- Outer label identifies MPLS LSP used to tunnel the packets across the MPLS network.
- Inner label used for payload multiplexing.
- LDP extended discovery signalling is used to associate... (see Andy's slides).
- RSVP-TE and CR-LDP used in the core.
- TDM header is sequence number and structure pointer, If you fix packet size
- at 783 octets, then the structure pointer can go away. Other items in original header may not be required.
- LDP extensions build on the Martini draft. Adds a new VC description for TDM.
- QoS requirements for CEM.
- Sending additional e2e alarm info in addition to AIS.
Q: How to extend timing for CEM?
- Two modes of timing recovery, synch and adaptive. If synch, then you use the -ve and +ve bits if there is a slip that needs to be reflected at the egress end. For adaptive, you can use the ATM mechanism.
- What if you lose the packet containing the slip indication. (need to read the draft, also ATM has excellent method of clock recovery defined).
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)
- Much of this duplicates what is in RTP already. See draft-white-sonet-format-rtp-00 in AVT.
- There are a number of similar drafts. Not mentioned is draft-mcpherson-l2tp-es-00.
- This draft can be seen as a functional specification.
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
Goals: provide a framework, unify terminology.
What you find is motivations, objectives, generic ideas of general models, options in specific areas, criteria for comparison.
Models: protection switching (pre-planned), reroute (post failure), lots of variations.
- Outlines recovery principles, concerns and associated options. (fault detection etc.)
- Requirements are fairly high level. Need more input and elaboration.
- Comparison criteria - recovery time, resource effy., degree of disruption, quality of backup, fault coverage.
- Change: cleaned up objectives, noted use of MPLS mechanisms for non MPLS traffic. Added concept of pre-qualified, not explicitly created for recovery, but usable. Also alternate egress repair, and other concepts.
- Goal is to have I-D adopted as WG document.
Multi company draft.
VoMPLS = VoIPoMPLS.
Goal, use MPLS for carrier class VoIP transport.
- I-D Objective, define a framework for the operation of VoIP over MPLS and how existing protocols can be used for this application.
- Where gaps are identified, the I-D proposes that they be filled by existing WGs.
- No specific BOF/WG, should be adopted by the new routing area WG and advanced to informational RFC.
- Reference model displayed. Includes a number of interworking scenarios.
- Applications - inter GW trunking, voice TE, BW effy on slow links (header compression), MPLS GoS/QoS.
- Data plane requirements: provide path for VoIP bearers, header compression, efficient muxing, delay bounding.
- Control plane consists of call and bearer control. Call control is common with VoIP.
- Bearer control, need intra domain bearer control. IWF between IP Qos and MPLS QoS.
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.