From l3vpn-bounces@ietf.org Mon Aug 06 14:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II7F2-0000i7-4h; Mon, 06 Aug 2007 14:23:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II7F0-0000hv-Jv for l3vpn@ietf.org; Mon, 06 Aug 2007 14:23:42 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II7Ex-0007Uf-Qi for l3vpn@ietf.org; Mon, 06 Aug 2007 14:23:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 06 Aug 2007 11:23:38 -0700 Received: from [172.23.1.175] ([172.23.1.175] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 14:23:20 -0400 Message-ID: <46B76709.7020204@juniper.net> Date: Mon, 06 Aug 2007 14:23:05 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2007 18:23:25.0986 (UTC) FILETIME=[E12B8020:01C7D856] X-Spam-Score: 0.0 (/) X-Scan-Signature: 539f8b288ab42db633e5c7cf1c34fca1 Subject: Minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Folks, The following are minutes from our last meeting. If there are no corrections, I will post them on Friday. Ron ================================================== WG status/charter - Ron/Rick ---------------------------------------------------------------------------- Ron - Only one or two docs left outstanding (mostly to do with multicast). So would be good to recharter. Virtual Routers etc. could come in - was taken off charter before. Anyone who wants VRs on charter can they please come to the mic? Hamid - unintelligible. Eric - I thought it was good to drop it. Seen same pattern over the years, nothing gets done until we threaten to do it when we get a flurry of work. Don't want to put on the charter unless there are lots of people interested. Ron - if you're interested in seeing VR completed raise hand. 3 hands. If opposed then raise hand. 5 hands. Do we take to mail list? Mark Townsley - unintelligible. Ron - will take to list and see if can get consensus one way or the other. Ron - next issue we talked about bringing was MPLS LSPs over L3VPN. Kenji will talk about this (signalling LSP from CE to CE through L3VPN). Is that work we'd like to see the WG doing? No comments... Sense of room... 3 hands. Does anyone not understand the question? Kireeti - do you have to be an SP to answer this? Ron - no, just in the room... any strong feelings? Luca - how does that relate to L1VPN? Ron - only diference is that it is for people who are already doing L3VPN. Mark - other difference is how deeply signalling from CE goes into SP's network. L1VPN is setting up Lambdas. This work is going over existing L3VPNs. Ron - sense of room. Anyone interested in bringing the work to the WG? 2 hands... Ron - next issue is authentication. Mechanisms that prevent misconfig (e.g. CE attached to L3VPN without authorisation) or mechanism to detect such attachment. had two past drafts, both went away for lack of interest. Sense of room as to whether people are interested. A few hands. Eric - are we just going to bring back old drafts and let them die again? Ron - will fire myself as editor and see who can advance it. Eric - that won't be sufficient. Seems like we ought to do this, but never been possible to get enough traction for any given method. Is it different this time? Rick - unintelligible. Shane - speaking as an SP I realise this has languished for a while but see it as fairly critical and with an operational use in our own network. Am surprised not been completed to date and strongly advocate we pick it back up. we face these problems on a daily basis and rely on legacy OSS to watch the network for us - would be much better built into the protocols themselves. 4 or 5 people interested. Will Shane be editor? Shane - don't have the time. But willing to contribute. Mark - when we have BoFs to start WGs we ask if people are willing to write text etc. And sometimes even "do we have employers who will support it". Of those people who said they'd like to see it done would anyone take over editorship of any of the docs? Shane - better to ask list. Many more people there than here. Mark - I wanted to at least get someone here. But let's go to the list... Ron - I don't see enough support for any of the 3 areas. will ask again on list... Multicast VPN - Eric/Rahul ---------------------------------------------------------------------------- Eric - tried to put finishing touches on this set of docs. Some finishing touches are bigger than others! 1) gone through and tried to clarify the notion of upstream multicast hop determination. In previous docs that was spread out so all in one place. 2) new notion of upstream-assigned PE labels (will discuss) 3) added more material on MP2MP LSPs as P-tunnels 4) added support for BIDIR-PIM by customers (never got around to up to now). (1) New Three Letter Acronym (UHM). Trying to carefully distinguish finding upstream PEs from the PIM notion of "RPF determination". Had complaints that the document didn't support load balancing, so added simple procedure. Uses a simple default hashing algorithm. can do more complex stuff if you want. There's work out there on multicast specific topology (OSPF MTR, BGP SAFI 2, etc.). Sets of routes only used for multicast. So incorporated that into the language for choosing the UHM. Introduced BGP SAFI 129 (VPN equivalent of SAFI 2). Another area where clarity was lacking was Single Forwarder Selection (SFS). Want all PEs to pick the same ingress PE for a stream. A multicast tree in a customer's network could have multiple points of entry, and you could end up with 2 copies of the packet through the backbone and to customer end systems. By inspection of BGP routes you can force all PEs to pick a single ingress PE. Or if a PE gets a packet from the "wrong" ingress PE then it won't forward towards the customer. There's a convergence time issue with using inspection of BGP routes. Why both procedures (ensure only send once, and discard if duplicates)? Both needed. Also PIM-BIDIR won't work with SFS. A third option is to use S-PMSIs. Don't have to do SFS as all PEs are bound to the S-PMSI. So can get multiple copies in backbone, but don't forward to multiple customer receivers. Doesn't work in all cases... (2) Upstream-assigned PE labels. A PE label identifies a PE. These are upstream-assigned in that the root PE for a multicast tunnel through the backbone assigns labels that identify itself to other PEs that are tunnel members. Have not identified a precise mechanism to distribute them, but planning to use BGP. upstream-assigned labels Will be unique per P-tunnel. We need this so that if P-tunnel is an MP2MP LSP then the egress PEs can identify the senders in order to do the discard procedure. When a P tunnel carries PIM-BIDIR then use PE label to identify designated forwarder. can use the same mechanism to identify the ASBR for an MP2MP intra-AS segment of an inter-AS tunnel. (4) C-Bidir support. In bidir PIM each root address is associated with an RP address (RPA). The RPA is just an address (doesn't need to be a box). Packets don't just go downstream from root but can go upstream towards root. At each branch point packets can start going downstream. This is a neat feature but has costs - e.g. loops that would not exist on unidir trees. Easy to see that doesn't happen on unidirectional tree. In Bidir copies are only bounded by TTL. Loops can occur on any multiaccess medium (LAN or MVPN PMSI). BIDIR PIM handles this with an elaborate DF election procedure (40 pages of the spec). In an MVPN context we want one PE to be DF towards the backbone. worked example of this. Issue is that multiaccess link creates a cycle in the tree. So if the backbone is modelled as multiaccess then can get cycles. DF election is one way to break the cycle. Will present other methods. DF election is regarded by many people as complicated. Last time I presented I showed a simple procedure for SFS forcing all PEs to choose same DF (for same C-RPA). Issue with that model is that convergence might not be fast enough to prevent packets looping. Other alternatives: i. simple scheme where RPA outsourced to SP. So each PE sees the RPA as reachable via the backbone. So the root is always the backbone and backbone can't create cycles. But of course this isn't transparent to existing customer multicast routing (and they may not wish to outsource the RPA). ii. don't remove cycles, but prevent packets from traversing cycles. So the ingress PE must choose a PE to be the DF and identify it in the P-tunnel encapsulation. So when an egress PE receives a packet from a P-tunnel it only forwards it if it would have picked the same DF as its ingress PE. So different DF choices won't cause looping. Can identify the DF either by using a PE label as the second label or by sending the packet on the MP2MP LSP whose root was the selected DF. When you partition the set of PEs then the only way to get to the other set of PEs is via the RPA. That's normal BIDIR procedure. Rahul - short update on v3 of the BGP MVPN draft. Various enhancements from previous version that are worth mentioning. 1) spec has clarified non-congruent unicast/multicast connectivity (SAFI 129 case). 2) clarified RR processing of next-hop. RR should set next-hop to self when re-advertising C-multicast routes (to reduce route churn). RR must not modify the next-hop when re-advertising inter-AS autodiscovery routes. 3) clarified that PMSI tunnel attribute is carried in intra/inter-AS AD routes if, and only if, an I-PMSI is used for the MVPN. next steps? Document is stable. Got assignments for codepoints (thanks to chairs). Have at least one implementation. For next revision we want extensions to support areas of new work being addressed by architecture doc. Ron - unintelligible. Rahul - will give you ETA by next IETF. We have some areas of new work... MVPN revisited - Maria Napierala ---------------------------------------------------------------------------- Another draft on MVPN! Discussing differences between this and other drafts. Usually get comments from the same people, so not sure how many people have read it. coming from SP area and see it as important not to have to choose a single forwarder. This draft addresses the issues with current proposal from Eric and Rahul, in that I believe we need to support multiple forwarders for the same (S,G). There are various drawbacks of single forwarders - e.g. removes the advantage of IPVPN where different VPNs can have different policies. Customers can't take advantage of that with single forwarder procedure (however that is done). want to point out that for any C-multicast procedure which is used to exchange customer multicast routes between PEs then aggregation of routes can't prevent there being multiple inter-PE paths for multicast traffic. We know from production networks that whatever we do must be transparent to the customer. Can't change states created on customer side. Larger customers usually have large networks behind the PEs - not just one single LAN... draft is about these procedures, but doesn't dictate what protocol is used to exchange the C-Multicast routes, or to transport the P-tunnels. All about discovering groups, when to announce etc. current experience is that VPN Customers are unhappy with MVPN. Today have to explain to customers that single forwarder behaviour will change in future. Only way to keep customers interested. As an SP we are interested in the service being a success. We must allow for multiple forwarders so customers can get benefit of IPVPN and so different egress PEs can join for the same source and same group. Today customers are asking SPs to change the PE loopback address to achieve the desired traffic patterns! Only way to achieve what we want is to adopt this draft! various changes in -01. Also -02 on way (too late for this IETF). Incorporated comments received privately. Also edited text to make it clearer and remove unnecessary text etc. main change to logic is distinction between co-located and non co-located source and RP. We can't change anything in customer sites in terms of the flow, what states are created, and where the states are created. So need the distinction to make that work. When the source and RP are not co-located can make simplifications (automatic switch to trigger use of SPT). From customer perspective it is transparent whether we switch to SPT or not. But if source and RP are co-located then customer will imediately see if we switch. Very small change to draft - but allows for some optimisations. If we make the distinction we can conform to customer SPT thresholds (e.g. if non-zero - for which customer may have a good reason). These procedures are described in version 01. If co-located then can simply send traffic from all co-located sources on same trees. New tunnel announcement route type, based on updated version of BGP draft. May not need a separate route, but just that the existing tunnel announcement for the PMSI has a wild-card for the source address. Doesn't matter how it is done, but just a tunnel that aggregates all sources at same site as the RP. added support for switchback to shared tree. Need to set signalling up. Also needed in non co-located case with dual homed receivers (SPT and shared tree may diverge - and can't assume that join of SPT and RPT go over the same link). given all the above we get automatic support of shared trees (didn't have in the -00 version). All completely transparent. Also get support of anycast C-RPs. Different receivers can join different RPs based on customer policy etc. Also added support for C-bidir trees. Agree that may have to be done in the more sophisticated case to avoid loops (am assuming single forwarder today). This can be changed so that it doesn't have any restrictions and has strong DF election procedure. procedure for scalability. C-BIDIR trees ideally could be autodiscovered. So even if customer uses PIM-SM then if we discover that most receivers are sources we could use MP2MP tree etc. need more details to finish this off. -02 adds S-PMSI auto-discovery route for active muilticast c-groups. used in c-bidir as only announce one tunnel per group. Have a note there as to how this can be done, but SP wouldn't want to go that way as not scalable. Also used in co-located C-S and C-RP so don't need to knmow specific sources. might be that you have sources sending traffic with no receivers. if you only build the tunnel when receivers come you'll have a delay. So have unconditional source so you can build the tunnel before receivers come along (optional if delay is not acceptable for some applications). support for fast reconvergence with single fowarder if DF-PE fails. So pre-build the tunnel from the secondary. procedure to support C-bidir trees using MP2MP tunnels. 2 slides explaining anycast C-RPs. Because of procedures in the draft there could be multiple forwarders. Allows multiple anycast C-RPs to send traffic in parallel to different receivers. By default if there is a tie then the highest IP address wins. But a VPN can use different multicast policy for different RPs. At AT&T we allow customers to have different routing policies for different VRFs. One option is to use SP's IGP cost. so customer may be willing to use that as it is generally based on distance. But should be an optional knob. Not all SPs have the same IGP design! Or some SPs may not want to expose IGP cost to customers... support for C-BIDIR. have simple DF-PE election right now (highest IP address). As Eric mentioned is not ideal, but could be made more complete, so then the procedure for announcing the tunnel is that is done when get a (C-*, C-G) join. tunnel announcement via S-PMSI auto-discovery route (when using BGP to announce tunnels). Again have option to announce tunnel if receive unconditional source traffic even though there are no active members. (PE announces the group C-G to DF-PE when it gets unconditional source traffic). next step is to adopt as WG doc and to get comments on the list. As an SP we're anxious to be able to explain to customers that what we have today will change. Also need to add tunnel aggregation procedures (need extra machinery to avoid duplicates), and support of C-BSR and C-Auto-RP. Yakov - same comment I made in private. Useful to have another iteration that reflects most recent changes to architecture and BGP procedures doc. Then can see what's missing if anything and decide whether to adopt this as a WG doc. Maria - only prob I have with that is current drafts are just signalling procedures (using BGP). Arch draft still does not address the single forwarder problem. Yakov - yes it does. It explains clearly that you don't have to have single forwarder. Maria - I have to check. Yakov - that's why I suggest you look at latest doc, see what's missing (if anything), and see if we need a new doc or to change existing procedure. Rahul - yakov said what I want to say. But please tell us what is missing in the latest docs and we'll fix it. Maria - I'm not sure of exact procedures for multiple forwarders. Rahul - it's in the document. Maria - is this in response to what I presented before? Not sure of process. Eric - there are lots of things in this doc. Deployment scenarios are worth putting in a separate doc. Other things are criticisms of the WG docs. Need to be clear precisely what those areas of disagreements are. If you have issues with WG doc you can't solve that by writing a new doc. Need to persuade people to change the existing doc. Don't see why we'd make this a WG doc. More of a basis for discussion. Ron (chair hat off). Can I recommend you get together with WG doc authors and see what is there, what isn't, what needs to be augmented, and what might need to be kept in a separate doc. Actually am saying that as WG chair. Maria - I know for a fact that because my 00 draft came before current docs, that I don't know if they're responding to my criticism or is something independent. would help me to see if are going in same direction. Originally the architecture doc had one forwarder. Rahul - lots of mis-communication here. I've spoken to you before, as have others who know MVPN well. You think there's functionality missing. That's not correct. once we have bridged the mis-communication then we can see what is missing. Maria - I want to see how doc supports multiple C-RPs. Rick - we've stated intention to last-call Eric/Rahul's docs around next IETF. So at that time can see what from Maria's doc needs to be addressed... Does that schedule work? Rahul - I'm happy to talk to Maria after this and see what's missing. Mark - there are three people here who just need to get in the same room and hash all this out. Then come back and say what was agreed upon. If that doesn't happen at this IETF am sure that as you don't live that far apart from each other you can do it before the next IETF. MPLS over L3VPN Kenji (with Raymond, Nabil) ---------------------------------------------------------------------------- motivation is to provide robust MPLS services to customers. Today we can do end-to-end paths from CE to CE using LDP, but not using RSVP-TE. We want RSVP-TE so can guarantee bandwidth and provide fast protection etc. aim is for all benefits of L3VPN (VRF per customer for security - can't forward through SP's instance and can't join SP's routing/signalling domain - and unique address space per VPN). The important thing here is that most SPs deploy L3VPN, not L1VPN. So don't see L1VPN as a solution... So aim here is to clarify issues for TE over IPVPN and models, scenarios, requirements. Reference model - C-TE LSPs established from C router to C router. P-TE LSPs from PE to PE. 3 scenarios (needed for NGN services). since last version we added Nabil as co-author, clarified the problem statement etc. now want to become WG doc. Rick - questions? Not seeing any. So will continue to look at adding this to charter. can't be WG doc unless added to charter. Support of RSVP in L3VPN (Bruce) ---------------------------------------------------------------------------- this draft may or may not be in this WG as also relates to TSV. so issue is customer of L3VPN wants to do admission control including on the CE to PE links. Won't work out of box, and will explain why. 2 main issues: 1) need to associate RSVP messages at PE with correct VRF context (not as easy as it appears) 2) path messages in RSVP are sent with router alert option - and need to get that to work. focus here is admission control, not TE. And primary focus is CE-PE links. Also may wish to do in backbone, but is separable problem. Main challenge is to aggregate in backbone as don't want per-customer state in backbone. diagram of how this is supposed to work. So path messages from sender to receiver and resv from receiver to sender. Resv must follow reverse path. Path messages are there to leave "breadcrumbs" for the resvs to follow. Assuming here that the paths and resvs won't be seen by core routers in SP network. proposed a solution in the draft. Been discussing other possible mechanisms with Yakov today. Two new objects designed to identify which VRF you should be processing the paths and resvs in. these will only appear inside the provider's backbone (so transparent to customer). one idea in the proposal is that the path messages rather than using router alert can be sent directly to the egress PE with that PE's destination address. Simplifies the data plane operation since don't have to worry about looking for router alert inside a packet which is wrapped in MPLS headers. For admission control in the backbone is very similar to RFC4804. So doing admission control over a tunnel as if it was a link. looking at details. Path message intercepted by ingress PE (because of router alert). RSVP code looks at it. Figures out what MPLS labels would be used if being sent as data and puts that in the RSVP message. Also figures out the VRF and puts a handle to that in the message and sends to the egress PE. No need for router alert as sending to egress. egress PE looks at the packet and gets VPN label and "real" IP address (can look up label and IP address - if needed - to identify the egress VRF and store that with path state).. Forwards to the CE with router alert. When resv received find the VRF and find the path state to send towards the ingress PE. At ingress PE you know the VRF (from the handle in the msg) and can use that to get path state, do admission control for the backbone (if needed) and send to the ingress CE. showing new objects for VPN label and VRF. addressing potential Qs (Yakov thought of more) 1) not using MPLS router alert because concerned about data plane support in existing PEs and wanted the control plane to be consistent with RFC4084. 2) put VRF ID and label in all "forward" messages and VRF ID in all "reverse" messages (so not just path and resv). 3) option A and C interprovider are easy. Looking at option B. 4) why do we need the VRF_ID when have existing HOP object in GMPLS. Issue is that HOP doesn't appear in all message types so using new object for all messages. in summary main goal is admission control on PE-CE links. In TSV WG have been doing lots of work on RSVP for admission control. So people are seeing more and more scenarios which they want to work. Hoping this is smallest possible set of scenarios to make this work whilst solving router alert issue. Also gives optional admission control over backbone... Yakov - there is an existing RFC (4208) that solves a superset of this problem. It discusses how GMPLS solves this. So look at 4208 section 7 and see if anything is missing. I think it is a superset, so just describe how to subset. Also GMPLS UNI is used in L1VPN which is, again, a superset of this problem. What you need is not new objects but a description of the subset you require. Bruce - doesn't look to me like is fully specified in that RFC. Yakov - if not then fix in that RFC Bruce - or elsewhere? Raymond - so in terms of PE to CE link don't care if is physical or logical? Bruce - yes, don't care. Raymond - is address of egress PE in global space or VRF space? Bruce - it's known in the SP's network. Ron (chair hat off) - you said you hadn't thought option B through. Wouldn't it be impossible to make it work in any scenario where the packet travels labelled to ASBR? Bruce - would need to process RSVP at ASBR. So RSVP wouldn't go from ingress PE to egress PE but ingress PE to ASBR to ASBR to egress PE, etc. Is the point you're getting at that if you put a label in the RSVP message then don't you know what the right label is if it is being swapped at the ASBR? Ron - right. Bruce - want to know if people think this should be done here or in TSV. Rick - again issue with charter. current charter says we don't address QoS. Already called into question by the last draft. Seems to be that what Bruce has proposed is pretty specific to L3VPN. So seems to be appropriate to do here. so think we need to add QoS to charter... show of hands in support of doing this in this WG? Many hands. Nobody objecting. Will allow input on list. From l3vpn-bounces@ietf.org Mon Aug 06 15:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II8X8-00072A-Ur; Mon, 06 Aug 2007 15:46:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II8X7-00071z-CS for l3vpn@ietf.org; Mon, 06 Aug 2007 15:46:29 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II8X4-00031u-54 for l3vpn@ietf.org; Mon, 06 Aug 2007 15:46:29 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 06 Aug 2007 12:46:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFIXt0arR7PE/2dsb2JhbACtLw X-IronPort-AV: i="4.19,225,1183359600"; d="scan'208"; a="510760134:sNHT48270696" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l76JkOMi031809; Mon, 6 Aug 2007 12:46:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l76Jk3WP007733; Mon, 6 Aug 2007 19:46:24 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 15:46:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Aug 2007 15:46:17 -0400 Message-ID: In-Reply-To: <46B76709.7020204@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes thread-index: AcfYVx63mJJK7kNlTOSDQDo1B51/4QACtfVw References: <46B76709.7020204@juniper.net> From: "Aamer Akhter \(aakhter\)" To: "Ron Bonica" , X-OriginalArrivalTime: 06 Aug 2007 19:46:18.0631 (UTC) FILETIME=[7518E970:01C7D862] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=28139; t=1186429584; x=1187293584; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aakhter@cisco.com; z=From:=20=22Aamer=20Akhter=20\(aakhter\)=22=20 |Subject:=20RE=3A=20Minutes |Sender:=20; bh=T8ILH7dC2j6GPcJA+C0LxKaSEjmY31F6QzAoJFNTOOs=; b=ud9VrcRIoCqYDpvjnQVSEVTcqgZdTjmbpu8LlkwcqhKMwJW9LMsbr8+3U3exC8tMKtEH7ext dlIqIHuB97akh9Lap0TRxjxoZahTXgf17Zje62vZvbjEBVhZM6S9/N4u; Authentication-Results: sj-dkim-4; header.From=aakhter@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e2982d6e88dd9e60a92963820c317d50 Cc: Subject: RE: Minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Ron/ Fellow L3vpn'ers, I'd be interested in working on the PE-CE auth mechanisms. There are = some interest items wrt catching misconfigs and notifications (as Shane = mentioned).=20 > Ron - next issue is authentication. Mechanisms that prevent misconfig > (e.g. > CE attached to L3VPN without authorisation) or mechanism to detect = such > attachment. had two past drafts, both went away for lack of interest. > Sense of room as to whether people are interested. A few hands. Regards, --=20 Aamer Akhter / aa@cisco.com Ent & Commercial Systems, cisco Systems > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net] > Sent: Monday, August 06, 2007 2:23 PM > To: l3vpn@ietf.org > Subject: Minutes >=20 > Folks, >=20 > The following are minutes from our last meeting. If there are no > corrections, I will post them on Friday. >=20 > Ron >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 >=20 >=20 > WG status/charter - Ron/Rick > = ----------------------------------------------------------------------- > ----- >=20 > Ron - Only one or two docs left outstanding (mostly to do with > multicast). > So would be good to recharter. Virtual Routers etc. could come in - > was > taken off charter before. Anyone who wants VRs on charter can they > please > come to the mic? >=20 > Hamid - unintelligible. >=20 > Eric - I thought it was good to drop it. Seen same pattern over the > years, > nothing gets done until we threaten to do it when we get a flurry of > work. > Don't want to put on the charter unless there are lots of people > interested. >=20 > Ron - if you're interested in seeing VR completed raise hand. 3 = hands. > If > opposed then raise hand. 5 hands. Do we take to mail list? >=20 > Mark Townsley - unintelligible. >=20 > Ron - will take to list and see if can get consensus one way or the > other. >=20 >=20 > Ron - next issue we talked about bringing was MPLS LSPs over L3VPN. > Kenji > will talk about this (signalling LSP from CE to CE through L3VPN). Is > that > work we'd like to see the WG doing? No comments... Sense of room... = 3 > hands. Does anyone not understand the question? >=20 > Kireeti - do you have to be an SP to answer this? >=20 > Ron - no, just in the room... any strong feelings? >=20 > Luca - how does that relate to L1VPN? >=20 > Ron - only diference is that it is for people who are already doing > L3VPN. >=20 > Mark - other difference is how deeply signalling from CE goes into = SP's > network. L1VPN is setting up Lambdas. This work is going over > existing > L3VPNs. >=20 > Ron - sense of room. Anyone interested in bringing the work to the = WG? > 2 hands... >=20 > Ron - next issue is authentication. Mechanisms that prevent misconfig > (e.g. > CE attached to L3VPN without authorisation) or mechanism to detect = such > attachment. had two past drafts, both went away for lack of interest. > Sense of room as to whether people are interested. A few hands. >=20 > Eric - are we just going to bring back old drafts and let them die > again? >=20 > Ron - will fire myself as editor and see who can advance it. >=20 > Eric - that won't be sufficient. Seems like we ought to do this, but > never > been possible to get enough traction for any given method. Is it > different > this time? >=20 > Rick - unintelligible. >=20 >=20 > Shane - speaking as an SP I realise this has languished for a while = but > see > it as fairly critical and with an operational use in our own network. > Am > surprised not been completed to date and strongly advocate we pick it > back > up. we face these problems on a daily basis and rely on legacy OSS to > watch > the network for us - would be much better built into the protocols > themselves. 4 or 5 people interested. Will Shane be editor? >=20 > Shane - don't have the time. But willing to contribute. >=20 > Mark - when we have BoFs to start WGs we ask if people are willing to > write > text etc. And sometimes even "do we have employers who will support > it". > Of those people who said they'd like to see it done would anyone take > over > editorship of any of the docs? >=20 > Shane - better to ask list. Many more people there than here. >=20 > Mark - I wanted to at least get someone here. But let's go to the > list... >=20 >=20 > Ron - I don't see enough support for any of the 3 areas. will ask > again on > list... >=20 >=20 > Multicast VPN - Eric/Rahul > = ----------------------------------------------------------------------- > ----- >=20 > Eric - tried to put finishing touches on this set of docs. Some > finishing > touches are bigger than others! >=20 > 1) gone through and tried to clarify the notion of upstream multicast > hop > determination. In previous docs that was spread out so all in one > place. >=20 > 2) new notion of upstream-assigned PE labels (will discuss) >=20 > 3) added more material on MP2MP LSPs as P-tunnels >=20 > 4) added support for BIDIR-PIM by customers (never got around to up to > now). >=20 > (1) New Three Letter Acronym (UHM). Trying to carefully distinguish > finding > upstream PEs from the PIM notion of "RPF determination". Had > complaints > that > the document didn't support load balancing, so added simple procedure. > Uses > a simple default hashing algorithm. can do more complex stuff if you > want. > There's work out there on multicast specific topology (OSPF MTR, BGP > SAFI 2, > etc.). Sets of routes only used for multicast. So incorporated that > into > the language for choosing the UHM. Introduced BGP SAFI 129 (VPN > equivalent > of SAFI 2). >=20 > Another area where clarity was lacking was Single Forwarder Selection > (SFS). > Want all PEs to pick the same ingress PE for a stream. A multicast > tree in > a customer's network could have multiple points of entry, and you = could > end > up with 2 copies of the packet through the backbone and to customer = end > systems. By inspection of BGP routes you can force all PEs to pick a > single > ingress PE. Or if a PE gets a packet from the "wrong" ingress PE then > it > won't forward towards the customer. There's a convergence time issue > with > using inspection of BGP routes. Why both procedures (ensure only send > once, > and discard if duplicates)? Both needed. Also PIM-BIDIR won't work > with > SFS. A third option is to use S-PMSIs. Don't have to do SFS as all > PEs are > bound to the S-PMSI. So can get multiple copies in backbone, but = don't > forward to multiple customer receivers. Doesn't work in all cases... >=20 > (2) Upstream-assigned PE labels. A PE label identifies a PE. These > are > upstream-assigned in that the root PE for a multicast tunnel through > the > backbone assigns labels that identify itself to other PEs that are > tunnel > members. Have not identified a precise mechanism to distribute them, > but > planning to use BGP. upstream-assigned labels Will be unique per P- > tunnel. > We need this so that if P-tunnel is an MP2MP LSP then the egress PEs > can > identify the senders in order to do the discard procedure. >=20 > When a P tunnel carries PIM-BIDIR then use PE label to identify > designated > forwarder. >=20 > can use the same mechanism to identify the ASBR for an MP2MP intra-AS > segment of an inter-AS tunnel. >=20 > (4) C-Bidir support. In bidir PIM each root address is associated = with > an > RP address (RPA). The RPA is just an address (doesn't need to be a > box). > Packets don't just go downstream from root but can go upstream towards > root. > At each branch point packets can start going downstream. This is a = neat > feature but has costs - e.g. loops that would not exist on unidir > trees. > Easy to see that doesn't happen on unidirectional tree. In Bidir > copies > are only bounded by TTL. Loops can occur on any multiaccess medium > (LAN or > MVPN PMSI). BIDIR PIM handles this with an elaborate DF election > procedure > (40 pages of the spec). In an MVPN context we want one PE to be DF > towards > the backbone. >=20 > worked example of this. Issue is that multiaccess link creates a = cycle > in > the tree. So if the backbone is modelled as multiaccess then can get > cycles. > DF election is one way to break the cycle. Will present other = methods. > DF > election is regarded by many people as complicated. Last time I > presented > I showed a simple procedure for SFS forcing all PEs to choose same DF > (for > same C-RPA). Issue with that model is that convergence might not be > fast > enough to prevent packets looping. Other alternatives: >=20 > i. simple scheme where RPA outsourced to SP. So each PE sees the RPA > as > reachable via the backbone. So the root is always the backbone and > backbone > can't create cycles. But of course this isn't transparent to existing > customer multicast routing (and they may not wish to outsource the > RPA). >=20 > ii. don't remove cycles, but prevent packets from traversing cycles. > So the > ingress PE must choose a PE to be the DF and identify it in the P- > tunnel > encapsulation. So when an egress PE receives a packet from a P-tunnel > it > only forwards it if it would have picked the same DF as its ingress = PE. > So > different DF choices won't cause looping. Can identify the DF either > by > using a PE label as the second label or by sending the packet on the > MP2MP > LSP whose root was the selected DF. When you partition the set of PEs > then > the only way to get to the other set of PEs is via the RPA. That's > normal > BIDIR procedure. >=20 > Rahul - short update on v3 of the BGP MVPN draft. Various > enhancements > from previous version that are worth mentioning. >=20 >=20 > 1) spec has clarified non-congruent unicast/multicast connectivity > (SAFI 129 > case). > 2) clarified RR processing of next-hop. RR should set next-hop to = self > when > re-advertising C-multicast routes (to reduce route churn). RR must = not > modify the next-hop when re-advertising inter-AS autodiscovery routes. > 3) clarified that PMSI tunnel attribute is carried in intra/inter-AS = AD > routes if, and only if, an I-PMSI is used for the MVPN. >=20 > next steps? Document is stable. Got assignments for codepoints > (thanks to > chairs). Have at least one implementation. For next revision we want > extensions to support areas of new work being addressed by = architecture > doc. >=20 > Ron - unintelligible. >=20 > Rahul - will give you ETA by next IETF. We have some areas of new > work... >=20 >=20 > MVPN revisited - Maria Napierala > = ----------------------------------------------------------------------- > ----- >=20 > Another draft on MVPN! Discussing differences between this and other > drafts. Usually get comments from the same people, so not sure how > many > people have read it. >=20 > coming from SP area and see it as important not to have to choose a > single > forwarder. This draft addresses the issues with current proposal from > Eric > and Rahul, in that I believe we need to support multiple forwarders = for > the > same (S,G). There are various drawbacks of single forwarders - e.g. > removes > the advantage of IPVPN where different VPNs can have different > policies. > Customers can't take advantage of that with single forwarder procedure > (however that is done). >=20 > want to point out that for any C-multicast procedure which is used to > exchange customer multicast routes between PEs then aggregation of > routes > can't prevent there being multiple inter-PE paths for multicast > traffic. > We know from production networks that whatever we do must be > transparent to > the customer. Can't change states created on customer side. Larger > customers usually have large networks behind the PEs - not just one > single > LAN... >=20 > draft is about these procedures, but doesn't dictate what protocol is > used > to exchange the C-Multicast routes, or to transport the P-tunnels. = All > about discovering groups, when to announce etc. >=20 > current experience is that VPN Customers are unhappy with MVPN. Today > have > to explain to customers that single forwarder behaviour will change in > future. Only way to keep customers interested. As an SP we are > interested > in the service being a success. We must allow for multiple forwarders > so > customers can get benefit of IPVPN and so different egress PEs can = join > for > the same source and same group. Today customers are asking SPs to > change > the PE loopback address to achieve the desired traffic patterns! Only > way > to achieve what we want is to adopt this draft! >=20 > various changes in -01. Also -02 on way (too late for this IETF). >=20 > Incorporated comments received privately. Also edited text to make it > clearer and remove unnecessary text etc. >=20 > main change to logic is distinction between co-located and non co- > located > source and RP. We can't change anything in customer sites in terms of > the > flow, what states are created, and where the states are created. So > need > the distinction to make that work. When the source and RP are not > co-located can make simplifications (automatic switch to trigger use = of > SPT). From customer perspective it is transparent whether we switch = to > SPT > or not. But if source and RP are co-located then customer will > imediately > see if we switch. Very small change to draft - but allows for some > optimisations. If we make the distinction we can conform to customer > SPT > thresholds (e.g. if non-zero - for which customer may have a good > reason). > These procedures are described in version 01. If co-located then can > simply > send traffic from all co-located sources on same trees. New tunnel > announcement route type, based on updated version of BGP draft. May > not > need a separate route, but just that the existing tunnel announcement > for > the PMSI has a wild-card for the source address. Doesn't matter how = it > is > done, but just a tunnel that aggregates all sources at same site as = the > RP. >=20 > added support for switchback to shared tree. Need to set signalling > up. > Also needed in non co-located case with dual homed receivers (SPT and > shared tree may diverge - and can't assume that join of SPT and RPT go > over > the same link). >=20 > given all the above we get automatic support of shared trees (didn't > have in > the -00 version). All completely transparent. >=20 > Also get support of anycast C-RPs. Different receivers can join > different > RPs based on customer policy etc. >=20 > Also added support for C-bidir trees. Agree that may have to be done > in the > more sophisticated case to avoid loops (am assuming single forwarder > today). > This can be changed so that it doesn't have any restrictions and has > strong > DF election procedure. >=20 > procedure for scalability. C-BIDIR trees ideally could be > autodiscovered. > So even if customer uses PIM-SM then if we discover that most = receivers > are > sources we could use MP2MP tree etc. need more details to finish this > off. >=20 > -02 adds S-PMSI auto-discovery route for active muilticast c-groups. > used > in c-bidir as only announce one tunnel per group. Have a note there = as > to > how this can be done, but SP wouldn't want to go that way as not > scalable. > Also used in co-located C-S and C-RP so don't need to knmow specific > sources. >=20 > might be that you have sources sending traffic with no receivers. if > you > only build the tunnel when receivers come you'll have a delay. So = have > unconditional source so you can build the tunnel before receivers come > along > (optional if delay is not acceptable for some applications). >=20 > support for fast reconvergence with single fowarder if DF-PE fails. = So > pre-build the tunnel from the secondary. >=20 > procedure to support C-bidir trees using MP2MP tunnels. >=20 > 2 slides explaining anycast C-RPs. Because of procedures in the draft > there > could be multiple forwarders. Allows multiple anycast C-RPs to send > traffic > in parallel to different receivers. >=20 > By default if there is a tie then the highest IP address wins. But a > VPN > can use different multicast policy for different RPs. At AT&T we = allow > customers to have different routing policies for different VRFs. One > option > is to use SP's IGP cost. so customer may be willing to use that as it > is > generally based on distance. But should be an optional knob. Not all > SPs > have the same IGP design! Or some SPs may not want to expose IGP cost > to > customers... >=20 > support for C-BIDIR. have simple DF-PE election right now (highest IP > address). As Eric mentioned is not ideal, but could be made more > complete, > so then the procedure for announcing the tunnel is that is done when > get a > (C-*, C-G) join. >=20 > tunnel announcement via S-PMSI auto-discovery route (when using BGP to > announce tunnels). >=20 > Again have option to announce tunnel if receive unconditional source > traffic > even though there are no active members. (PE announces the group C-G > to > DF-PE when it gets unconditional source traffic). >=20 > next step is to adopt as WG doc and to get comments on the list. As = an > SP > we're anxious to be able to explain to customers that what we have > today > will change. Also need to add tunnel aggregation procedures (need > extra > machinery to avoid duplicates), and support of C-BSR and C-Auto-RP. >=20 >=20 > Yakov - same comment I made in private. Useful to have another > iteration > that reflects most recent changes to architecture and BGP procedures > doc. > Then can see what's missing if anything and decide whether to adopt > this as > a WG doc. >=20 > Maria - only prob I have with that is current drafts are just > signalling > procedures (using BGP). Arch draft still does not address the single > forwarder problem. >=20 > Yakov - yes it does. It explains clearly that you don't have to have > single > forwarder. >=20 > Maria - I have to check. >=20 > Yakov - that's why I suggest you look at latest doc, see what's = missing > (if > anything), and see if we need a new doc or to change existing > procedure. >=20 > Rahul - yakov said what I want to say. But please tell us what is > missing > in the latest docs and we'll fix it. >=20 > Maria - I'm not sure of exact procedures for multiple forwarders. >=20 > Rahul - it's in the document. >=20 > Maria - is this in response to what I presented before? Not sure of > process. >=20 > Eric - there are lots of things in this doc. Deployment scenarios are > worth putting in a separate doc. Other things are criticisms of the = WG > docs. Need to be clear precisely what those areas of disagreements > are. If > you have issues with WG doc you can't solve that by writing a new doc. > Need > to persuade people to change the existing doc. Don't see why we'd = make > this > a WG doc. More of a basis for discussion. >=20 > Ron (chair hat off). Can I recommend you get together with WG doc > authors > and see what is there, what isn't, what needs to be augmented, and = what > might > need to be kept in a separate doc. Actually am saying that as WG = chair. >=20 > Maria - I know for a fact that because my 00 draft came before current > docs, > that I don't know if they're responding to my criticism or is = something > independent. would help me to see if are going in same direction. > Originally the architecture doc had one forwarder. >=20 > Rahul - lots of mis-communication here. I've spoken to you before, as > have > others who know MVPN well. You think there's functionality missing. > That's > not correct. once we have bridged the mis-communication then we can = see > what > is missing. >=20 > Maria - I want to see how doc supports multiple C-RPs. >=20 > Rick - we've stated intention to last-call Eric/Rahul's docs around > next > IETF. So at that time can see what from Maria's doc needs to be > addressed... > Does that schedule work? >=20 > Rahul - I'm happy to talk to Maria after this and see what's missing. >=20 > Mark - there are three people here who just need to get in the same > room and > hash all this out. Then come back and say what was agreed upon. If > that > doesn't happen at this IETF am sure that as you don't live that far > apart > from each other you can do it before the next IETF. >=20 >=20 > MPLS over L3VPN Kenji (with Raymond, Nabil) > = ----------------------------------------------------------------------- > ----- >=20 > motivation is to provide robust MPLS services to customers. Today we > can do > end-to-end paths from CE to CE using LDP, but not using RSVP-TE. We > want > RSVP-TE so can guarantee bandwidth and provide fast protection etc. > aim is > for all benefits of L3VPN (VRF per customer for security - can't > forward > through SP's instance and can't join SP's routing/signalling domain - > and > unique address space per VPN). >=20 > The important thing here is that most SPs deploy L3VPN, not L1VPN. So > don't > see L1VPN as a solution... >=20 > So aim here is to clarify issues for TE over IPVPN and models, > scenarios, > requirements. >=20 > Reference model - C-TE LSPs established from C router to C router. P- > TE > LSPs from PE to PE. >=20 > 3 scenarios (needed for NGN services). >=20 > since last version we added Nabil as co-author, clarified the problem > statement etc. >=20 > now want to become WG doc. >=20 > Rick - questions? Not seeing any. So will continue to look at adding > this > to charter. can't be WG doc unless added to charter. >=20 >=20 > Support of RSVP in L3VPN (Bruce) > = ----------------------------------------------------------------------- > ----- >=20 > this draft may or may not be in this WG as also relates to TSV. >=20 > so issue is customer of L3VPN wants to do admission control including > on the > CE to PE links. Won't work out of box, and will explain why. >=20 > 2 main issues: >=20 > 1) need to associate RSVP messages at PE with correct VRF context (not > as > easy as it appears) > 2) path messages in RSVP are sent with router alert option - and need > to get > that to work. >=20 > focus here is admission control, not TE. And primary focus is CE-PE > links. > Also may wish to do in backbone, but is separable problem. Main > challenge > is to aggregate in backbone as don't want per-customer state in > backbone. >=20 > diagram of how this is supposed to work. So path messages from sender > to > receiver and resv from receiver to sender. Resv must follow reverse > path. > Path messages are there to leave "breadcrumbs" for the resvs to = follow. > Assuming here that the paths and resvs won't be seen by core routers = in > SP > network. >=20 > proposed a solution in the draft. Been discussing other possible > mechanisms > with Yakov today. Two new objects designed to identify which VRF you > should > be processing the paths and resvs in. these will only appear inside > the > provider's backbone (so transparent to customer). >=20 > one idea in the proposal is that the path messages rather than using > router > alert can be sent directly to the egress PE with that PE's destination > address. Simplifies the data plane operation since don't have to = worry > about looking for router alert inside a packet which is wrapped in = MPLS > headers. >=20 > For admission control in the backbone is very similar to RFC4804. So > doing > admission control over a tunnel as if it was a link. >=20 > looking at details. Path message intercepted by ingress PE (because = of > router alert). RSVP code looks at it. Figures out what MPLS labels > would > be used if being sent as data and puts that in the RSVP message. Also > figures out the VRF and puts a handle to that in the message and sends > to > the egress PE. No need for router alert as sending to egress. egress > PE > looks at the packet and gets VPN label and "real" IP address (can look > up > label and IP address - if needed - to identify the egress VRF and = store > that > with path state).. Forwards to the CE with router alert. When resv > received find the VRF and find the path state to send towards the > ingress > PE. At ingress PE you know the VRF (from the handle in the msg) and > can use > that to get path state, do admission control for the backbone (if > needed) > and send to the ingress CE. >=20 > showing new objects for VPN label and VRF. >=20 > addressing potential Qs (Yakov thought of more) >=20 > 1) not using MPLS router alert because concerned about data plane > support in > existing PEs and wanted the control plane to be consistent with > RFC4084. >=20 > 2) put VRF ID and label in all "forward" messages and VRF ID in all > "reverse" messages (so not just path and resv). >=20 > 3) option A and C interprovider are easy. Looking at option B. >=20 > 4) why do we need the VRF_ID when have existing HOP object in GMPLS. > Issue > is that HOP doesn't appear in all message types so using new object = for > all > messages. >=20 > in summary main goal is admission control on PE-CE links. In TSV WG > have > been doing lots of work on RSVP for admission control. So people are > seeing > more and more scenarios which they want to work. Hoping this is > smallest > possible set of scenarios to make this work whilst solving router = alert > issue. Also gives optional admission control over backbone... >=20 > Yakov - there is an existing RFC (4208) that solves a superset of this > problem. It discusses how GMPLS solves this. So look at 4208 section > 7 and > see if anything is missing. I think it is a superset, so just = describe > how > to subset. Also GMPLS UNI is used in L1VPN which is, again, a = superset > of > this problem. What you need is not new objects but a description of > the > subset you require. >=20 > Bruce - doesn't look to me like is fully specified in that RFC. >=20 > Yakov - if not then fix in that RFC >=20 > Bruce - or elsewhere? >=20 > Raymond - so in terms of PE to CE link don't care if is physical or > logical? >=20 > Bruce - yes, don't care. >=20 > Raymond - is address of egress PE in global space or VRF space? >=20 > Bruce - it's known in the SP's network. >=20 > Ron (chair hat off) - you said you hadn't thought option B through. > Wouldn't it be impossible to make it work in any scenario where the > packet > travels labelled to ASBR? >=20 > Bruce - would need to process RSVP at ASBR. So RSVP wouldn't go from > ingress PE to egress PE but ingress PE to ASBR to ASBR to egress PE, > etc. > Is the point you're getting at that if you put a label in the RSVP > message > then don't you know what the right label is if it is being swapped at > the > ASBR? >=20 > Ron - right. >=20 > Bruce - want to know if people think this should be done here or in > TSV. >=20 > Rick - again issue with charter. current charter says we don't = address > QoS. > Already called into question by the last draft. Seems to be that what > Bruce > has proposed is pretty specific to L3VPN. So seems to be appropriate > to do > here. so think we need to add QoS to charter... show of hands in > support of > doing this in this WG? Many hands. Nobody objecting. Will allow > input on > list. From l3vpn-bounces@ietf.org Thu Aug 16 13:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILjO6-000435-OA; Thu, 16 Aug 2007 13:44:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILjO5-00042o-68 for l3vpn@ietf.org; Thu, 16 Aug 2007 13:44:01 -0400 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILjO4-0006Ld-0e for l3vpn@ietf.org; Thu, 16 Aug 2007 13:44:01 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.verizonbusiness.com (Iplanet MTA 5.2) with ESMTP id <0JMV0003RNVTYL@firewall.verizonbusiness.com> for l3vpn@ietf.org; Thu, 16 Aug 2007 17:43:05 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([127.0.0.1]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JMV00574NVTZ5@dgismtp03.mcilink.com> for l3vpn@ietf.org; Thu, 16 Aug 2007 17:43:05 +0000 (GMT) Received: from XS344V8061891 ([153.39.146.193]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JMV005B6NVMG0@dgismtp03.mcilink.com> for l3vpn@ietf.org; Thu, 16 Aug 2007 17:43:05 +0000 (GMT) Date: Thu, 16 Aug 2007 13:42:58 -0400 From: Dave McDysan To: l3vpn@ietf.org Message-id: <005701c7e02c$e32034b0$c1922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcfgK3xRTRkC5Ay9R4+t5UKMiv6XYg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: MPLS 2007 International Conference - October 28-31, Washington DC X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org The 10th Annual MPLS 2007 International Conference will be held at the Omni Shoreham Hotel in Washington, DC from October 28-31, 2007. The 4-day event consists of technical sessions, tutorials, panel discussions, and exhibits. Program details are available at: www.mpls2007.com