Subject: L3VPN agenda slots at IETF80 (aka does L3VPN need to meet)?

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 5 Jan 2011 18:46:59 +0000

Colleagues,

Registration for IETF80 is now open and as I mentioned in my e-mail to the mailing list on 16th November last year, we will take a different approach to building the L3VPN agenda to what we have done in the past.

If you would like a slot at IETF80 can you please respond to this message including at least the chairs & Daniel King (cc'd) with details of the topic/draft you would like to cover and the amount of time you would like to request.

Please send your requests by midnight PST on 19th January.

After the 19th the WG chairs will assess whether there are enough requests to justify requesting a meeting slot at IETF80 or whether mailing list discussion or a virtual interim meeting is a more suitable method for progressing those pieces of work.

Thanks
Ben

---

From: "Peter Kao" <[email-masked]>
Date: Wed, 12 Jan 2011 21:08:02 -0800

Dear Colleagues, L3VPN working group,

I have recently submitted three drafts for standards track consideration; 

http://tools.ietf.org/html/draft-kao-pb-l3vpn-00 
This document describes a method by which a Service Provider may use an 
IEEE 802.1ad PBN (Provider Bridge Network) to provide IP Virtual Private 
Network Service for its customers.  This method extends the BGP/MPLS IP 
VPN service to allow IP VPN service to be offered using a PBN instead.  

http://tools.ietf.org/html/draft-kao-pbb-l3vpn-00 
This document describes a method by which a Service Provider may use an 
IEEE 802.1ah PBBN (Provider Backbone Bridge Network) to provide IP 
Virtual Private Network Service for its customers.  
This method extends the BGP/MPLS IP VPN service to allow IP VPN service 
to be offered using a PBN instead.  

http://tools.ietf.org/html/draft-kao-path-binding-bgp4-00 
When BGP is used to distribute a route, it can also be used to
distribute a Link Layer PATH_NEXT_HOP binding which is mapped to that   
route such that packets to that network route can be switched directly 
across an Ethernet switched network.

The motivation for using PB/PBB rather than an MPLS core for IP/VPN is as
follows - As flat mobile networks (4G/LTE, mobile WiMAX, HSPA+ flat, and
UMB) emerge, IP routing is being pushed more and more from the Metro Core
towards the Metro Access and Aggregation networks to provide support for
single IP-RAN and any-to-any IP connectivity between base stations. The
current, existing Metro Ethernet Backhaul infrastructure in place based on
PB can't support routed flat mobile network with any-to-any IP connectivity,
it just can't do routing. As such, IPMPLSForum20.0.0 proposed an all MPLS
access/aggregation/core network solution to support flat mobile networks
with L3VPN capability.

The submitted drafts propose a way to enable existing and new Metro PB
switched access/aggregation networks with IETF RFC4364 L3VPN capability for
the emerging flat mobile networks and converged Metro transport with L1, L2,
and L3 support.  

Cordially, I would like to invite you to an open discussion on the mailing
list and give all of us a precious opportunity to hear your feedback and
thoughts.

Thx & Regards,
Ares, P., Kao
[email-masked]

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 27 Jan 2011 11:58:53 +0000

Colleagues,

We only received requests from two people to present at IETF80 so Marshall and I have decided there is not the critical mass required to request a face 2 face session.

The two requests we received were:
1) Wim & John Drake asked to present the entropy label draft and how to apply it to L3VPNs. However, they also plan to present the draft in the MPLS WG.

2) Peter Kao asked to present 3 drafts on L3VPNs[1] using a layer 2 PB/PBB core. These are new (-00) drafts and haven't seen any discussion on the mailing list yet. We'd encourage folks to read those drafts and discuss them on the mailing list. 

Regards
Ben

[1]