Subject: IETF 62 minutes

From: Ronald Bonica <[email-masked]>
Date: Thu, 10 Mar 2005 10:49:00 -0500

Folks,

If there are no objections, I will post the following minutes on March 
18. Thanks to Marshal Eubanks and Mark Duffy for their notes.

                                    Ron
-----------------------------------------------------------------

IETF 62 - L3 VPN

March 7 at 13:00 CST

Chairs

Ron Bonica <[email-masked]>
Ross Callon <[email-masked]>
Rick Wilder <[email-masked]>

Ross Callon  - Document Status Review

Generic Requirements have been published as RFC 3809.

L3 framework is waiting on a normative references on
Generic and L3 Service Requirements.

Security Framework has been approved.

BGP-MPLS L3 VPN's is in the RFC editor's queue.

VR and CE/IPSec architecture documents are all under
IESG consideration.

AS Guidelines are "done"

Terminology is also about to be published.

The MIBs need a little more work.
Frame - done subject to comments from IESG
Textual Conventions is done
MPLS / BGP MIB - subject to comments from IESG

Virtual Router MIB timed out but has been recently updated. There
is an intellectual property issue. This needs guidance from the working
group.

Multicast is one of the things where we are doing current work. The
Requirements Draft has just been accepted as a WG document.
There are also other individual drafts.

Other WG documents

OSPF needs to be updated to respond to IESG comments.
PE-PE IPSec for 2547 needs updates based on last call comments.

PE-PE GRE is under discussion with the IESG.

BGP Autodiscovery has been sent to the IESG

---

Thomas Morin - Multicast Requirements

draft ietf-l3vpn-ppvpn-mcast

Context : First draft was presented in Washington, now a L3 VPN WG
document. Integration of comments from new contributors.

This added 6 pages. Many areas of the document are now quite stable.
Noteworthy changes are Security, QOS, Internet Multicast, RP
engineering.

Internet Multicast is currently only mentioned as a possible
requirement, so if the group has strong feelings about this, the
group should speak up.

Fragmentation  issues - special care is needed here for multicast.

Recently, added text about supporting multicast in a "Carrier's
Carrier".

The service providers side requirements have evolved.

- control mechanisms
- security
- tunneling requirements - need to cleanly separate the control plane
and the forwarding plane
- TE  & OAM

A terminology session has also been added.
A new term, Multicast Distribution Tunnels, or MD tunnels, has
been added.

What's next ?

There is a need for data about the types of applications,
orders of magnitude

However, need to consider not just current deployments but also future
deployments.

Also, support for the Carrier's Carrier model needs to be added.

Open questions include the scope of the document. Should the scope
be reduced ? Should IPv6 be added ?

He requests review and comments from the WG. He also wants to do
an ISP survey.

--
Multicast VPN Architecture

Eric Rosen  ([email-masked])
and Rahul Aggarwal ([email-masked])

Multicast Support for RFC 2547 VPNs has 2 components

control plane - exchange vpn multicast routing information

data plane

This is very similar to the separation for 2547 unicast.

Design Objectives include

Optimize Bandwidth & Optimize State

- A given multicast packet should traverse a given link at most once
- Deliver multicast traffic only to those PE's that have receiver that
want the traffic.

Optimizing State and Bandwidth are conflicting goals.

MVPN AutoDiscovery uses BGP
- this eliminates PIM Hello's

Control traffic does not have to use the tunnels used by the multicast
data.

In the data plane

- ingress replication to egress
- a separate tree for every C-(S,G)

going one way increases state and decreases bandwidth, going the other
way does the reverse.

Can do aggregate state, with a separate state for
"Inclusive mapping"

or "Selective Mapping" - a separate tree per set of C-(S,G)

The tree is built using PIM-SM BiDir, SSM, whatever.

The spec does not limit to a specific tree building protocol.

<audience member> - ask questions now, or at the end ?
Ross - at the end

Eric Rosen

In order to converge the document, tried to see how the proposals
differ.

- What sort of multicast service can be provided
- methods of implementing multicast service
- multicast routing information propagation

One size does not fit all, so tried to clarify multicast service
and routing information exchange.

Provider-Network Multicast Service Interface - PMSI

- service is scoped to one MVPN
- three types

MI-PMSI - multipoint inclusive, all to all
YU-PMSI - unidirectional
S-PMSI - selective

PMSI's are instantiated by tunnels. Types of these

PIM-created trees
Point to MultiPoint LSP's

Unicast tunnels

PMMSI may require sets of tunnels (e.g., SSM)

Single tunnel may instantiate more than one PMSI

- the encapsulation is a function of the tunnel, not the service

Old terminology -

Default MDT -> MI-PMSI, instantiated by PIM shared tree or a set of PIM
Source Trees

Data MDT = S-PMSI

New terminology helps to separate out the service and data issues.

What sort of tunnels ?

MPLS vs GRE vs MPLS in GRE vs ...

Source initiated or receiver initiated creation of tunnels
TE : Source
Multicast : Receiver

Options for creating
and destroying the tunnels

As part of discovery
As a separate phase after discovery
As needed (this complicates the protocol options)

How do we ensure interoperability - force a common tunnel choice ?

The discovery phase - make sure that everyone gets all of the multicast
information that they require.

What PMSI's are going to be used ?
Will MVPN routing be propagated by unicast or multicast

What sort of tunnels ? What information is needed to create and destroy
them.

What encapsulation is to be used ? What amount of aggregation.

For routing information, they considered only PIM and BGP.

For PIM, C-Join / Prune messages are sent by either multicast
or unicast (PE to PE).

Note : Unicast is different from MI-PMSI over unicast tunnels.

With PIM, you can minimize overhead by eliminating periodic
messages

- refresh reduction (being worked on in PIM group)
- hello suppression (provided by BGP in L3VPN)

This creates a lightweight adjacency which is, however, not
interoperable with  full adjacencies.

Can always find the RPF, even if there isn't always a route back to the
source.

Control Messages : Multicast or Unicast

Allows asserts, join suppression, standard "PIM on a LAN"

Unicast : No join suppression, no asserts

OR, you can do it with BGP

BGP MVPN Routing information update (new SAFI)
<RD, C-S, C-G, ORIGINATOR PE, Upstream PE - PE2, RT>

I-PMSI Instantiation -
Can be uni or multi directional

Current spec limits trees to PIM-SM, SSM, BiDir, RSVP-TE P2MP LSP's

Trees can be source based or shared trees.

Source tree's are set up by the PE
Shared trees are set up by a RP

**** except that they say with 				
**** SSM

Each PE uses BGP to advertise whether or not it is capable of
MPLS ingress replication, and also downstream MPLS Label

Joins are sent upstream using BGP or Unicast PIM
[as there is no full mesh tunnel. Wonder if they have thought about
MSDP ?]

Aggregation allows one P-Multicast Tree to be shared across _multiple_
VPNs'.

Requires a MPLS label to demultiplex a particular VPN -
BGP to the RR.

A PE decides to set up an aggregated tree :

S-PMSI instantiation

Set up a separate tree for a set of <C-S, C-G>s that
may belong to different VPN's

This also allows a datagram (UDP) based protocol that may already be
deployed.

For inter-AS - two models

Tunnel Span's multiple AS's

OR

Each AS can have its own tunneling mechanism

The draft talks about deployment models.

- Anycast RP based on (*,G) advertisements

When you unicast PIM messages, how do you know which VPN they
belong to ?

Authors request to make it a wg doc.
Also, they invite the authors of draft-yasukawa to join for the next draft

---------
Seisho Yasukawa (NTT)

BGP/MPLS IP Multicast

Basic ideas

1. Extend BGP to exchange multicast routing information
2. Adopt a proxy RP
3. Use P2MP TE LSP to  forward multicast traffic over provider
core

There mechanism is applicable to PIM SM and SSM

They want to merge the drafts into a single MVPN solution

Question :
Marshall Eubanks : How do you plan to
do anycast RP ? Currently it is done with MSPD

A : Using a new SAFI in BGP

Question :
Yiqun Cai : How do does the customer do BiDir ?

A. BiDir is not supported.

Ross : It is my impression that in both authors have expressed a
desire to merge the two documents. What is the consensus of the working
group ? Should these be merged ?

Rahul Aggarwal : Just to make it clear, our draft tried to incorporate
as much as possible of the other draft already.

Yakov Richter : So we don't have to wait for the next IETF.

Ross: we have limited time here for discussion.  Shall we ask the 
authors to merge proposals?
Shall we accept it now as wg doc once it is merged?  Or wait until we 
see it?
Many more hands for accepting it now.
A: Let's get the merged doc on the mailing list and proceed from there.

------
Michael Behringer
draft-behringer-mpls-vpn-auth-05.txt

RFC2547 environment

If a PE misconfiguration a CE onto a tunnel, this could be a security
problem, and there is no easy way to detect it.

There is routing authentication

Proposal - Do away with PE to PE authentication, do authentication
across the entire tunnel.

There is another draft, the Bonica draft. There was a push to merge
them, but he thinks now that this does not make too much sense.

                        Draft:     Beh Bon
CE Does not need to participate   No  Yes
Allows route verification by site No  Yes
Work with route reflectors       YES  YES
Requires routing PE-CE           YES  (Yes, or a new functionality to
do this)

Q (McDysan):  as an SP, he likes this.  Doesn't want to rely on 
customers to detect problems.

Q (..., cisco): What prevents using same md5 key for  more than 1 CE?
A: nothing; that's tough luck

---
Ron Bonica

CE Based Membership verification

We are worried about honest mistakes from the Service provider

Status Quo : L3 VPN relies on the proper configuration of the Service
provider network. Breaches are generally silent.

The proposed mechanism alerts the customer when the VPN has been
breached.

A VPN site sends a token to the PE, which sends it to every other
site.

This does not protect against malicious behavior on the part of the
SSP, intended to protect against accidental exposure.

This draft and the Behringer draft actually solve rather different
problems. One partially prevents configuration errors, the other alerts
the customer when it happens.

[could you concatenate your token with a MPLS label or some other
unique ID]

Ross : Who thinks that these are a bad idea ?

Rick Wilder : I think that each author should make it clearer what
authentication problem it is solving, and also have pointers to
the other draft.

[Audience member] Each one solves a piece of the problem. Putting them
together implies that we solve the entire problem, which we probably do
not have the bandwidth for.
So, keep them separate, but keep them bound together, though.

Q (Rosen): is this really solving a different problem
A: yes, because ...

Ross:  who has read both drafts?
    only 9 hands
    most of those 9 think both should be progressed
Ross: anyone who thinks either idea is a bad thing to progress?  None.

Rick Wilder: we need to make it more clear in draft each how they relate 
to each other.

Townsley:  Keeping them separate allows more flexibility to advance them 
(or not).

----
draft-defeng-l3vpn-ipv4-ipv6-hybrid-01
www.huawei.com

Two cases

Both backbone and sites are v4 and v6 hybrids

Case 2 : IPv4 backbone with IPv4 / v6

Method 1 Case 1 : Carry IPv4 and IPv6

map v4 address to 96+MASK if necessary.

Packet forwarding between PE-sites

Method 2 for Case 1

multi-hop MP-EBGP set up based on IPv4

Case 2

PE assigns private IPv4 addresses for IPv6 site, and supports a
NAT-PT for these sites

Add an extra attribute for these sites, IF-V6-Site,

Wants this to become a WG draft.

------
draft-kulmal-l3vpn-aggregation-pe-00.txt

Uses a mechanism that is a hybrid of 2547
chapter 10 option a and b

Advantages : Routes are associated to VPNs and
IP packets are accessible.
Very granular TE is possible.

One "Con" is that it needs to keep VPN routers in ASBR routers, which
may lead to state issues if it is widely used.

Q (Rahul): Isn't it just an implementation difference from option B?
A: no because ...

---

From: "Marco Carugi" <[email-masked]>
Date: Thu, 10 Mar 2005 17:42:50 +0100

Ron,Ross and Rick, 

You may also want to add to the document status review 
section of the minutes that the L3 VPN requirements draft is 
going to be published these days (finally!) as RFC4031 (it's 
currently in the RFC Editor's 48 hours authors stage).
 
Thanks, Marco