Subject: draft minutes from the L3VPN meeting in Vancouver

From: "Rick Wilder" <[email-masked]>
Date: Fri, 2 Dec 2005 13:52:24 -0500

Here are draft minutes from the Vancouver L3VPN meeting. 

Many thanks to Eric Fleischman and Benson Schliesser for taking notes.

Rick, Ron, and Ross

----------------------------------------------------------------------------
----

L3VPN WG meeting:               November 10, 2005                 Vancouver

Chairs: Ross Callon, Ron Bonica, Rick Wilder

Status of the WG:

Ron Bonica reviewed the WG status and docs. 
 
.        While many drafts are in progress, by far the most active work area
is multicast.

*	The status of the L3VPN documents is summarized by the datatracker
utility at https://datatracker.ietf.org/public/pidtracker.cgi
<https://datatracker.ietf.org/public/pidtracker.cgi> .

Martin Halstead presented a draft on a proposed new Inter AS Option for
BGP/MPLS IP VPN:

*	Deals with VPNs spanning multiple service provider (SP) domains or a
single SP with multiple ASes
*	The two use cases have different requirements. When spanning SP
domains, the concern is with hiding VPN topology information and allowing
policy mediation, including supporting load balancing and path optimization.
There is a possible need for multi-hop eBGP based VPN service extensions. A
single SP with multiple ASs deals with requirements to segment the network
for increased scalability.
*	There are pros and cons for each of the three options. Option A
gives you separation for various domains with the RD, RT, and PE addresses
separated at the AS border. This is the most commonly deployed alternative
by SPs despite its cons, which include scaling issues associated with per
VRF attachment circuit BGP sessions and difficulty to support enterprise QoS
transparency (due to dependencies on L2 media).
	Option B is good for scaling of ASBR control and data plane with
support for enterprise QoS Transparency. However, its disadvantage is that
it requires agreement and coordination of route target values across SPs,
including trust required between SPs as MPLS-based "global" interface
exposures. There also is no per VPN route capping or summarization such that
there are operational process separation issues.
	Option C is not being used by service providers so it wasn't
covered.
*	This draft is proposing a combination of Options A and B. Use MPLS
based data plane between ASBRs with single MP eBGP peering between ASBRs. It
hides intra-AS topologies and has enterprise QoS transparencies. 
*	Asked if there is any working group interest in this option (e.g.,
to update the draft). There wasn't time for the discussion so will be moved
to the mailing list.

Requirements for Multicast in L3 VPNs by Thomas Morin, Renaud Moignard and
others.

*	A Multicast VPN survey of 30 questions was put out on July 27th.
Results were gathered in September 2005. Responses were of varying quality
but did enable them to identify use cases and to identify deployment order
of magnitude information. 

	*	Number of VPNs should scale up to thousands of VPNs
	*	Number of VPNs per PE should scale up to thousands of VPNs
per PE.
	*	Number of CEs per VPN per PE - scale to several hundreds
(and target thousands)

			*	Number of PEs connected to multicast sources
ranged from 1, 2, 5 or 10 (e.g., for content distribution) to hundreds.
			*	Should support hundreds or thousands of
streams per VPN.

	*	Their conclusion is that no solution should restrict the
scope of multicast applications and deployments that can be one over a
multicast VPN. They also identified some use cases that may impact the
solution design.
	*	They still have several open questions: (1) Inter-AS, (2)
multi-homed sources and Inter-AS, and (3) Inter-provider security.
	*	They reported that the draft is mature and nearing readiness
for working group last call soon. 
	*	Again, no time was allowed for questions.

Eric Rosen's and Rahul's Multicast in BGP/MPLS VPNs

Discussed MVPN improvements. Control plane needs to scale better and the
data plane needs more aggregation as well as tunnels on a per-VPN or coarser
basis. Question about the control integration is whether or not to reuse
general L3VPN mechanism. Want to eliminate the requirement for
Multi-directional Inclusive P-Multicast Service Interfaces (PMSIs)

*	MI-PMSI-based control and have more flexibility in choosing
tunneling technologies.
*	There is a tension between scale verses optimality and the "known to
work" versus "being invented now". On the control plane there is the issue
of integration versus optimization. Also, what will the bottleneck be: the
data or control plane. There is also the problem that multicast has
unpredictable demands.
*	The group is not trying to improve the multicast protocol itself or
address non-MPVPN issues.
*	Data MI-PMSI makes it easier to handle dense mode and flooding-based
applications.
*	With MI-PMSI in the control plane, PIM Asserts can be used to create
efficient routes by specifying "designated forwarder".
*	Concerning BGP specifically, BGP is the L3VPN PE-PE signaling
mechanism that gives it advantages for PE-PE multicast signaling. However
the scaling needs to be carefully examined, together with dynamics.
*	Presentation is trying to discourage over-enthusiasm for BGP such
that other viable approaches should still be considered.
*	Discussed Basic BGP interactions, including S-State and R-State
scaling issues.

Rahul then spoke about the functionality in BGP that they have built.
Intra-AS is well understood but Inter-As has more issues. Uses MVPN
auto-discovery with inter-AS tunnels being constructed by stitching together
intra-AS tunnels between providers, even if each provider is actually using
a different multicast protocol internally. MVPN PE-PE routing exchange
between ASes only occurs at ASBRs or RRs. Use RT Constrain to limit the
distribution of auto-configuration information. 

These have BGP extensions for MCAST VPN NLRI consisting of the RD, Src PE
address, C-Source length, C-Group length, and MPLS labels.

Gargi: arch is cleaner if we separate discovery from binding
Rahul: thanks for comment; if we can leverage same encoding then is
reasonable, but functions are separate

Xiaohu Xu ([email-masked] <mailto:[email-masked]> ) discussed Multicast in
BGP/MPLS VPN (draft-xu-l2vpn-2547bis-mcast-01)

*	Discovery of MVPN membership is by auto-discovery, followed by the
establishment of pseudo-wires. This is the main difference from Eric Rosen's
draft.
*	Addressed questions he received over the mail list.

.         Ron calls for hands, who read? <5, so discussion will continue on
the email list. 

Yiqun Cai, Mike McBride, and Chris Hall on MVPN Experience
(draft-ycai-mvpn-experience-00)

*	Describing their multicast experience to help ISPs with their
deployments
*	Their current deployment uses the multicast domain model and uses
PIM/IGMP/MSDP between the PE/CE. It uses PIM in the core and GRE (class D)
encapsulation. There is a different mapping functionality between default
MDT and Data MDT. Also used MDT SAFI for source discovery.
*	Their draft discusses their lessons learned and best practices for
RPF, load balancing, PIM modes most commonly used by service providers,
addressing, filtering, upgrade, etc. 
*	Their approach is well deployed and supports all of the known
multicast applications and end-to-end multicast protocols of the ISP
customers. It also leverages existing multicast protocols in the core and
allows migration to future enhancements such as p2mp/mp2mp LSP and
Join/Prune reduction.
*	Yakov Rekhter said it is a very useful document but asked that
quantitative analysis of scaling be added and that corrections be made to
the QoS section. Ross Callon subsequently agreed, especially for documenting
the scaling numbers.
*	Ted Seely emphasized that multicast is not easy in service provider
networks and it will be tougher yet to get it to work between service
provider networks.

.        Yiqun requested others with deployment experience to send results.
 
.         Ross: (regular-guy hat) this doc assumes single approach
(PIM-based). Yiqun: it is the only deployed approach. Ross: if other
deployments exist, their input would be valuable too
 
.        Ted Seely commented that some of the scaling numbers in the survey
are too low
 
.        Thomas Morin: we can still take responses, are interested in more
data

MVPN PE-PE Signaling by Nidhi Bhaskar, Yiqun Cai and Gargi Nalawade. Gargi
presented:

*	This presentation is part of a study concerning how to convey PIM
information within BGP (e.g., to potentially migrate historic LAN-based PIM
into the L3VPN BGP mechanism). Replaces PIM on LANs with a RR.
*	PIM LAN procedures are well understood and well deployed. The
authors suggest BGP for provider multicast routing in this working group.
This is an analysis of the BGP enhancements and impact upon BGP/PIM.
*	Identifies the changes to BGP needed to support the PE-PE multicast
signaling. This includes new functions in BGP such as aggregating D-PE, U-PE
based filtering, and RPF lookup on ASBR, Multicast PE-PE (overlay) SAFI,
RT/RD Import/Export, filtering, PIM/BGP interaction, and Inter-AS procedures
and interactions.
*	A separate speaker then continued the presentation, discussing
BGP-multicast routing state. The RR stores each multicast route as N * NLRI
where N is the number of D-Pes interested in the multicast stream,  Putting
PIM Join/Prune in BGP requires PIM Join/Prune to be routed as a BGP NLRI.
This has latency implications. There are PIM State machine changes to
interact with BPG such as no PIM hellos for option negotiation - options may
be carried in BGP. BGP is really not appropriate for PIM Assert resolution.
PIM-SM shared tree pruning is also difficult because BGP cannot preserve the
full state nature of the PIM prunes. The BSR mappings also require a full
state update.
*	Other issues with BGP is that BGP will not restrict the Binding
state to the multicast tree. There are also not enough bits to encode SAFI
length for IPv6. Need to also define transition mechanisms from LAN
procedures to BGP.
*	Dino asked the authors concerning whether this approach is easier or
harder than traditional PIM uses. Gargi answered that zero-configuration
support will be a differentiating factor. Her partner said that the new
environments will have environments without LANs with which to run PIM.
*	Beau Williamson asked whether their approach has removed the upper
bound limits as far as multicast consumption of ISP resources. This approach
seems to support arbitrarily growing (possibly exponential) demands on
service provider so that maybe the customers could bring the ISP down.
Presenter agreed that there will be an additional load. Also there is a
fundamental difference between how PIM joins and prunes would work.

Bin Lee presented IPv6 VPN Address Format.

*	Is a new L3 VPN solution based on the structure of IPv6. The goal is
to reduce packet overhead.

.        Bob Hinden: you're proposing to create site-local again, you should
read about why it was deprecated, it's unlikely to be accepted by iesg/ietf;
you're taking an amount of space equal to what all RIRs have today for this
scheme, which is unlikely; I think you can do everything with Unique
addresses, ULA inside
 
.        Alain Durand: is like double NAT, so double the problems; is very
expensive
 
.        Elwyn Davies: all of the above; also, you'll have trouble routing
these non-aggregatable addresses globally
 
.        Mark Townsley : what does this solve that normal L3VPN encapsulated
over an IPv6 network can't solve?
 
.        Discussion of this point to be continued on the mailing list.