Subject: [Fwd: IETF66 L3VPN meeting minutes]

From: Ron Bonica <[email-masked]>
Date: Sat, 15 Jul 2006 21:35:31 -0400

Folks,

Please review these minutes. If there are no objections, I will post
them on Friday.

                                    Ron

Layer 3 Virtual Private Networks (Internet Area)

Friday, July 14, 2006
=======================

Chairs:
Rick Wilder <[email-masked]>
Ron Bonica  <[email-masked]>

Agenda:

Minutes: Steven Blake ([email-masked])
Chair (Ron) presents agenda

/* Note: didn't catch names of Y and W. */

09:00-09:10  Working Group Status - R. Bonica

Document status

Question on a document's desired track (which document?)
- Eric Rosen: informational
Proposal for MVPN MIB, went on back burner.  Authors have asked to make
it a wg draft (placeholder).  Consensus call on draft-sidea (sp)
Rahul ?: MIB is way off from the solution.

09:10-10:00  Multicast Solutions - E. Rosen
		draft-ietf-l3vpn-2547bis-mcast-02.txt
		draft-raggarwa-l3vpn-2547bis-mcast-bgp-02.txt

MVPN update
- progressing
- some sites receive-only, some transmit-only
Issues to discuss today
- Eliminating (S,G,R) prunes from BGP control plane
  - reduces state and complexity
  - two alternatives:
    - 1. MSDP-based
      - each C-RP talke MSDP to a PE
Comment Toerless Eckert: MSDP is only experimental
    - 2. Coordinated switch
      - CE switches to (S,G)
Comment Toerless: reemphasize that we shouldn't depend on MSDP (took five 
                  years to realize it wouldn't work).
Comment Yakov R: would it be better to use PIM register messages to get 
                 active sources?
Comment Rahul Aggarwal: proposal uses MSDP from CE-PE, and BGP source actives
                        from PE-P & PE-PE
    - both methods use BGP-based source active messages
Comment Eric R: PIM was experimental for 10 years
- Support for C-bidir trees (from enterprise)
  - assume unidirectional P-tunnels
  - PIM bi-dir has complex forwarding rules
  - choose one ingress PE for bidir tree
  - multi-AS C-bidir
- Use of MP2MP P-LSPs
  - intra-AS tunnels
    - for every mcast flow
      - single ingress PE designated transmitter (have procedure for this)
      - really a matter of aggregating p2mp tunnels into an mp2mp tunnel
      - dependency on work-in-progress in MPLS wg
Toerless: why do you need to identify where it is coming from?
Eric R: which is downstream, which is upstream?  If you don't, and there is
        not complete agreement as to the designated forwarder
	Toerless: sure, like LAN, not doing any strong RPF check in PIM, 
	don't need to know the "l2 identify" of the device.
Eric: PIM has 40 pages on selecting designated forwarder
Toerless: Only matters during DF election.  If this makes sense, it shouldn't 
          only apply to MVPN.
Eric: that was the original design choice, but there might be some period of
      time (during convergence) where two routers might think they are the
      DF.  BGP procedures might not converge fast enough.
Toerless: goes against IETF's decision for PIM standard
Thomas ?: we are not relying on dataplane procedures to prevent multiple
senders to sending downstream.  Only works as soon as all downstream PEs have
the same view of unicast routing.  Definitely a need to identify the sender
of the mcast traffic.
Toerless: what about bidir PIM?
Eric: Mcast tunnel?  Will work that out.
Y: PIM-SSM has check there already.  Don't know why you have to do this in 
PIM-SSM case.
Rahul: If you are using undir trees in the backbone, you already know the
       sender.
Toerless: if using GRE tunnels, you already know the sender.
  - MP2MP LSPs aggregating segments of inter-AS tunnels
    - inter-AS tunnels always p2mp
    - inter-AS segments of inter-AS tunnels are therefore inherently p2mp.
    - would like to aggregate these within an AS

Rahul Aggarwal presents:
- New auto-discovery (AD) route types
  - S-PMSI AD route
- Source Active AD route
  - used to advertise active source
- C-Multicast routing protocol
  - C-multicast route dampening described (prunes, joins, leaf AD routes)
  - C-mcast route aggregation (via RR and ASBR)
- Next steps 
  - procedures for MSDP or PIM Anycast RP between C-RP and PE based scheme
  - procedures for using BGP or RSVP-TE as the PE-CE protocol for Carrier's
    Carrier model (for future study)

10:00-10:15  Reqs for MPLS Services Over L3VPN - Kenji Kumaki (KDDI)
		draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01
- Motivation
  - robust MPLS services to customers
    - can offer e2e paths using LDP
      - can't offer e2e paths using RSVP extensions
    - offer CE-CE TE LSPs with guaranteed BW
    - want VRF instances per-customer to avoid security issues
      - customer can't join SP's routing/MPLS signaling domain
- Reference model diagram
  - C-TE LSPs
  - P-TE LSPs (encapsulates C-TE LSPs)
- Reqs
  - C-TE LSPs over BGP/MPLS IP-VPN (carrier's carrier & basic BGP/MPLS IP-VPN)
- Changes from -00
  - added author Raymond Zhang
  - changed problem statement
  - changed terminology
  - added admission control support
- Other requirements?
- Next actions
  - need wg feedback
  - request wg accept ID
Andy Malis: premature to accept as wg document, need to discuss mor on the
            list
Mark Townsley: engage L1VPN as well
Kenji: motivation is l3vpn (already deployed)
Mark: question of review, see overlap, don't want to step on toes (because
      CEs are setting up LSPs), want to make sure not solving problem in two
      places.  PWE3 also talking about generic PW.  Several areas are reacting
      to this motivation (CE-originated LSPs).  Add "work with other wgs"
      in next-actions.
Yakov: L1VPN is optical LSPs only.  Should you recharter L1VPN to work on
       packet environment.
Mark: understand, but same control plane
Yakov: please recharter L1VPN
JP Vassur: Mark is right.  Is this part of the discussion in l3vpn?
Chair Rick: yes
Adrian Farrel: circulate this in other wgs
Kireeti: important that the mechanisms used be common (l3 service & l1 service)o
         can use common mechanisms.
Eric: Want a PW, need to find out CE router to peer with
Rahul: You want RSVP-TE for carrier's carrier, right?  carrier's carrier fits
       within scope of this wg.

10:15-10:30  Proposal for MPLS Services Over L3VPN - R. Bonica
		draft-bonica-mplsvpn-00

- Imagine L3VPN service provider
- Customer wants to purchase a customer LSP from C0 to C3.
- Problem: customer wants to use RSVP-TE to signal the LSP, but that
  won't work.
- Solution:
  - Carrier's carrier nearly solves the problem.  Build SP-LSP between
    PE1 and PE2, use BGP to advertise labeled paths between CE1 and CE2
  - Need to build LSP between C0-CE1 and CE2-C3, CE1-CE2 is a virtual path
- Challenges:
  - RSVP signal C0-CE1-CE2-C3
  - Make CE1 beleive that next-hop to C3 is CE2
    - not PE1
    - three proposed solutions
      - BGP next-hop attribute
      - iBGP
      - policy manipulation
  - Partial ERO calculation
    - C0-CE2
    - CE2-C3
  - TE considerations
    - C0 and C3 need to see CE1-CE2 LSP for TE purposes
- Questions?
Rahul: Think this is carrier's carrier.  Why doesn't it fit in the wg's
       charter?
Chair Rick: Think it does.  Packet-based CE-CE LSPs are in charter
Yakov: what new is required to implement this (on top of 2547)
Ron: from customers pov, nothing.  From SP's pov, need a few things (missed
them).
Yakov: policy doesn't require standards work.  Is it correct to say that the
only thing needed is a TE attribute, why do we need to recharter wg.
JP: Where do we do the work?
Yakov: in the bar
Kireeti: someone needs to provide the napkin
Eric: Does this depend on carrier's carrier.  Might not want carrier's carrier
      service.  Need to find the CE endpoint if not using carrier's carrier,
      need a mechanism.  Have you thought about multihoming?
Ron: Yes, but not presented here.
Kireeti: please show slide with two PE1s
         Emphasize that CE LSPs takes C0-CE1-CE2-C3, don't drop state in
	 PEs.
Ron: required that CEs cannot create RSVP state in PE routers
Kireeti: this is different from l1vpn, where they are dropping state in PEs.
         CE1-CE2 is a pseudo-TE path, depends on accuracy of TE info
	 propogated from PEs; PE1-PE2 LSP could be oversubscribed.
Ron: right
Kireeti: not a req that provider actually runs RSVP-TE
Rajeev Sari (sp?): might be missing the CE-PE link BW reservation
Ron: agreed
Lee Ann Phang (sp?): does this force provider to implement certain TE
                     mechanisms?
Rajeev: (missed comment)
Eric: why focus on TE?  could use LSP for anything.  Are the reqs focused on
      TE?
Ron: could expand reqs
Rajeev: has something like multi-hop RSVP been considered?
Ron: no
Rahul: it works today
Rajeev: has it been considered
Ron: no
Lee Ann: req needs to be more clear, what is the req for the SP.  SP must
         also promise to offer TE.
Yakov: 2547 allows customer to originate RSVP-TE request from CE1-PE1,
       will be propogated to PE2
Loa: security issues with running LSP across customer-SP border
Ron: traffic restricted to VPN sites of the same customer; cannot install
     state in SP network
Loa: not convinced, some malicious party in customer net could launch DoS,
     need to address this in security considerations
Lee Ann: if I offer carrier's carrier, then I am basically done.  If customer
         wants a TE LSP, then somthing additional needs to be done (protocol
	 change)
Ron: need to leak TE info
Yakov: been implemented by Cisco, part of communities, can spec different
       attribute
Ron: need to keak info in BGP
Rajeev: could be running IGP & LDP on PE-CE
Ron: must use BGP for carrier's carrier
Rajeev: no; works today
Ron: you're right
W: ask previous authors if the services discussed are the same (IP over LSP)
Kenji: provide both cases

Mark Townsley: WG charter needs updating in general.  Carrier's carrier not
  in charter, TE (QoS) is excluded.  AD will recharter.

Consensus call on this work item: do in this wg?
- favorable; confirm on mailing list, updating of charter

Meeting adjourned