Subject: Text version of L3VPN minutes

From: Ross Callon <[email-masked]>
Date: Fri, 10 Dec 2004 14:43:50 -0500

Here is a text version of the working group minutes. The slightly better
looking Word version and those presentations that I have will appear in
the proceedings.

Thanks, Ross
-------------------------------------------------------------

L3VPN meeting minutes IETF-61
Mon 8 Nov 2004
===================

Thanks to Mark Duffy for minutes.

Agenda

	Agenda bashing and scribe discovery.

	Working group document status

	Multicast Requirements (Thomas Morin / Elodie Hemon)
		<draft-morin-l3vpn-ppvpn-mcast-reqts-00.txt>

	Multicast Approach (Eric Rosen)
		<draft-rosen-vpn-mcast-07.txt>

	Multicast Approach (Rahul Aggarwal)
		<draft-raggarwa-l3vpn-mvpn-vpls-mcast-01.txt>

	Multicast Approach (Seisho Yasukawa)
		<draft-yasukawa-l3vpn-p2mp-mcast-00.txt>

---------------------------------------------------------------------
Working Group Document Status (Ross Callon)

Ross went through the status of various working group documents. Note that we
have had several approved by the IESG since the last IETF, and have multiple
additional documents that have passed working group last call and are 
currently
being reviewed by the IESG and/or being updated in response to IESG comments.

Generic requirements - has been published as rfc3808

L3 Framework - in rfc editors queue for 18 mos, waiting normative ref on
service reqts (wrt which we have good news)

L3 Service requirements - has been approved by the IESG and is now in rfc
editor queue. This is good both in its own right, and also because it frees
up the L3 Framework to be published.

Security framework - almost done.  1 or 2 issues remain.

BGP/MPLS VPN Spec and Applicability Statement - these have been approved by
iesg, and are therefore now in the rfc editor's queue.

Virtual Router Architecture and associated Applicability Statement - these are
still under IESG review.

CE / IPsec Architecture and associated Applicability Statement - these are 
still
under IESG review.

Terminology draft - Has been approved by iesg, in rfc editor's queue

Thomas Narten:  Texts need to make it more clear that some of these docs are
frameworks etc. not standards.

Framework for l3vpn oam - This has just passed working group last call and 
been
sent to iesg

Textual conventions - Ditto (has just been sent to iesg)

MPLS / BGP MIB - This has passed wg last call and been submitted to the IESG.

Virtual Router MIB - This is waiting for an update by the document authors.

BGP auto discovery - Has passed working group call and been submitted to iesg.

ospf as pe/ce protocol - Has passed working group last call in both L3VPN and
OSPF working groups, and been sent to iesg

bgp/mpls for IPv6 vpn - This is ready for wg last call.

PE-PE IPsec for 2547 - in working group last call, an update is needed to
respond to comments received.

PE-PE GRE/IP for 2547 - Has been submitted to iesg.

CE-CE Member Verification - draft has timed out; the chairs have prodded
authors.

Constrained VPN Route Distribution - Has passed working group last call and
been submitted to iesg.

Eric Rosen:  2547bis is waiting in the RFC editor queue for BGP Extended
Communities to be published, which in turn is waiting for the base BGP spec.

Question from the working group chairs:  Who here is interested in IS-IS as
CE-PE protocol for 2547?  There was no response.

--------------------------------------------------------------------------------------
Requirements for multicast in Provider Provisioned IP VPNs
(Elodie Hemon, France Telecom)  draft-morin-l3vpn-ppvpn-mcast-reqts-00

Many solutions have been proposed for multicast over L3VPNs. No multicast
requirements document has been written yet.  Operator feedback may help in
developing and chosing between multicast solutions.

The requirements are intended to be solution-agnostic, and will serve as a
guideline for solution drafts.

There is a tradeoff between use of Bandwidth vs state in routers

Need:
   scalability, tunability, traffic engineering,
   versatility (vis-a-vis tunneling modes),
   inter-AS, inter-provider support
   monitor/troubleshoot capabilities
   robustness and infrastructure security

Open questions:
   Extranet support?
   Fragmentation issues?  MTU management.
   Control mechanisms
   Need use cases
   Carrier's carrier

Next steps:
   Integrate received feedback
   Want more feedback!

Questions:

(???): Tunnel mode agnostic:  is it v4/v6 agnostic?

(Chen Yin Lee): Is it layer agnostic too :-) ?  Some of this may apply to
L2 also.

(John Ryan?, Cisco): this is useful work.  Solutions should say which
requirements are met.

(???) - What are the important applications?  A: We don't care what the
content is.  Q: But from providers' POV, what is the application, what
are the bandwidth reqts?

(Jamie Miles, L3 Communications): Multicast is very important!  We *Need*
inter-provider; including all 3 2547 inter-provider approaches.

(???, Cisco): Requirements should be application-agnostic.

(???, Cisco): Should Internet multicast as a transit service be included?
Fragmentation should be avoided completely.  In IPv6 mcast should default
to 1280 MTU; this is a good practice for v4 too.

(Luyuan Fang): This is good, should continue this effort.  This effort
should focus on VPN, not Internet multicast.  Doesn't see many customers
for Internet multicast.

(Alex Zinin):  The security requirements section is empty!  <Something>
about long list of tunnelling protocols.

Ross: show of hands to interested to make wg doc: many in favor,
none/few opposed.

-----------------------------------------------------------------
Multicast in MPLS/BGP IP VPNs
(Eric Rosen, Cisco)  draft-rosen-vpn-mcast-07

Mcast for 2547:
  New to wg charter, but the work has been ongoing since 1998
  Many proposals now, all based on same basic architecture
  There is significant (but not massive) deployment
  There are multiple vendors with deployed multicast over L3VPNs
  (but "less than 3"  :-)

The new proposals extend, generalize, improve scalability.

How to proceed:
   Break arch into a few pieces and look at them separately
   Focus on producing standard, not battle between exisiting implementations.

Contentious issues:

  Mcast distribution trees in SP backbone
     Not much Internet mcast but fair amount of enterprise mcast

  Scaling issues. There is a tradeoff between:
     state in P routers
     packets carried more than once over the same link
     packets sent to PEs that have no receivers

  Single vs multi provider

  Traffic engineering

  PE-PE PIM adjacencies in PE's PIM C-Instance
    "Just as bad as the Virtual Router approach!"
    PIM hellos overhead
    PIM join/prune messages overhead
    Transparency to existing enterprise multicast structure.

MDT in SP: P-State Scaling

Base proposal uses hierarchical aggregation
   All groups from one VPN share a tree
   Requires state in P routers
   ...

Further scaling needs further aggregation
   by hierarchy?  seems elegant but no proposal.
   by some sort of TE?  figure out how some VPNs can share a tree.
   other ways?

Traffic load scaling
   Unaggregated MDTs are better at scaling traffic load (reduce multiple
   transmissions per link, packets sent to uninterested PEs)

What's with all the aggregation, de-agregation, reaggregation?
   Are we thrashing?  Reaching the limits of the technology?  ...

Proposal for demux using mpls encap
   Requires enhancement to mpls arch: context label, upstream label 
distribution
   Need to worry about IP-based encaps as well.

Do default MDTs provide enough aggregation?  Not enough to support unlimited
growth. Need more aggregation.

Scaling conclusion:
   One size doesn't fit all.
   The most scalable schemes may be too expensive in traffic loading.

Technology to create the MDT?

PIM-based solutions:
   PIM-SM - extremely complicated.  Source trees.
   PIM-SSM - much simpler.  Needs bgp-based source discovery
   BIDIR - best P-state scaling for intra-AS.

Explicitly routed MDTs (p2mp rsvp-te)
   Might be useful in some environments

Unicast tunnels with replication at ingress
   Optimizes P-state, poor for traffic load

Doesn't think we can throw any of these approaches out!

Scaling PE-PE interaction in PIM C-instance
   Some optimizations that can be made ...
   Should bgp be used to distribute mcast routes across the backbone?
     tempting but...

------------------------------------------------------------------------------------------------
Multicast in BGP/MPLS VPNs and VPLS
(Rahul Aggarwal, Juniper)  draft-raggarwa-l3vpn-mvpn-vpls-mcast-01

Components of 2547 mcast:
   control plane.  PE-CE; PE-PE
   data plane forwarding

Issues raised at last ietf:
   PE control plane state
   PE control plane processing load
   P state

Comparison of costs of 2547 unicast vs multicast
   why multicast doesn't scale as well
   ...

Design objective
   Optimize bandwidth
     Packet traverses a given link only once
     Deliver mcast packets only to interested PEs
     Deliver customer mcast traffic along optimal paths (support different
       algorithms to compute the trees)
   Optimize state:
     Amount of state and processing to maintain it should not exceed those
       for unicast.

Solution
   Existing solutions are insufficient
   This is a work in progress
   This solution tries to be reusable across L3 and L2 (VPLS) VPN
     But this presentation is only re l3vpn.

   Use BGP to do PIM neighbor maintenance
     Discover MVPN membership via BGP
     Reliable delivery of C-Join/Prune

   Allow multiple VPNs to share a single SP MDT ("Aggregate Data Trees")
      Set up via PIM or P2MP MPLS TE LSPs, or etc.
      Requires an inner label to demux a particular vpn
      State in SP network does not grow proportionate to # of vpns.
   Ingress Replication - has its place.

Aims to meet the requirements and have scaling properties similar to 2547
unicast.

------------------------------------------------------------------------------------------
BGP/MPLS IP Multicast VPNs
(Seisho Yasukawa, NTT)  draft-yasukawa-l3vpn-p2mp-mcast-00

Motivations:
  Qos, reliable mcast, adequate operation and mgmt
  Focus on L3
  Scalable arch
    avoid PIM adjacency maintenance
    avoid suboptimal IP packet distribution
  Flexible operation

Basic model:
  Adopt BGP/MPLS network model (CE peers with PE, use BGP for membership
  discovery)

  Extend bgp for exchange of mcast routing information

  Proxy-Source/RP model:  all PEs act as proxy-source/RP

  P2MP TE based MDT interconnects PEs

BGP

  Use MDT-SAFI to discover PEs of same vpn
  ...

Characteristics

   PIM-SM, PIM-SSM supported with same model

   Multiple topologies of MDT

   Multi-AS operation
   ...

Open issues

   Applicability of PIM-DM and PIM-BIDIR

   Optimize default/data p2mp tree operation
   ...

Next steps

   Resolve open issue

   Need wg input
     Is p2mp te mpls applicable to MVPN?

   Cooperate with other solution teams to develop a SINGLE solution.

---------------------------------------------------------------
Questions on all 3 approach presentations:

(???, Cisco): Q for Rahul: We should try to make PIM more efficient. ...
Source replication seems to just be moving complexity from core to PEs.
PIM join suppression improves scalability.

(??? Japan Telecom): ...(minute taker didn't record comment)

(Ali Sajassi, Cisco): re data tree and aggregating it.  As # of sites
goes up, chances of PE receiving packets not interested in goes up.  Would
like to see a description of this congruency mapping in the draft.  Will
customer's tree be moved from one aggregate to another?  Also, issue re
VPLS - treatment of customer data vs customer bridge protocol.

(Phil Zeckert???):  Need metrics to compare the different costs we are
trading off.  Suggestion: average bandwidth per tree: if over a particular
level, then perhaps give it its own tree.  Are we over-engineering now,
especially given the rollout rate?

(Yakov Rehkter): Re the last comment: It served us well in 2547 to
engineer for a large scale!  And anyway it will take years to roll
out whatever we do now. We should worry only about L3 traffic here.
Aggregation: avoid artificial boundaries about what can be aggregated.

(Eric Rosen): Yes, keep L2 and L3 separate.

   Re aggregation toolkit:  Easier for equipment vendor, but just passes
   the buck to the SP to decide what to do.

   Re Yasukawa proposal:  is this just PIM refresh reduction?  Making
   PE a RP brings a lot of complications with it.  Also a problem if
   enterprise has its own PIM infrastructure.  <one more point>

(Yakov): The Yasukawa approach is not just PIM refresh reduction; each
PE is a separate PIM domain which is very different than the Aggarwal
and Rosen approaches.  Could extend this scheme to not create MDT until
there is data traffic.

(???, cisco):  For Yasukawa-san:  question about putting Joins into bgp?
Since Join/Prune are modeled as SAFIs, how will route reflectors handle
them?  Wants to see more in the draft on this.

(??? cisco): Question for Rahul ...(minute taker did not record question)

(???):  Communications between multicast people and mpls people has not
been that great.  Will talk mode at mboned BOF this afternoon.

The authors of the three proposals agreed to try to work together
offline. The meeting was ajourned.