IETF 70 minutes

[Ron Bonica <rbonica at juniper.net>]

Folks,

Thanks to David Sinicrope for scribing our meeting at IETF 70. I have
already posted his notes to our web site. If anyone sees any
inaccuracies, I will gladly correct them.

                                Ron

Layer 3 Virtual Private Networks (Internet Area)

Wednesday, December 5, 2007
=========================

Chairs:
Rick Wilder <rick at rhwilder.net>
Ron Bonica  <rbonica at juniper.net>

Agenda:

09:00-09:10  Working Group Status and Charter - R. Bonica, R.Wilder
Ron did a brief update, we only have multicast VPN left to do.



09:10-09:40 T. Morin - draft-morin-l3vpn-mvpn-considerations-01
Thomas presented slides on the draft.
goal: discuss the options proposed and choose the better candidate
Question from Cisco, clarification do you need a colocated RP?  Yes.
would like additional clarification of colocated RP and usage in the draft.
Plan for refining the following subjects (slides) 5
test abou tspmsi for the inter AS context
comparison of segmented/nonseg inter as depending on  unicast option b or c
security or OAM related issues that cand ifferenciate the different propsoed options
Contributions welcom
expanding scope of document is not planned

need to identifiy a core set of mandatory procedures to make document useful as a standard
proposed as a WG draft.
those that read the draft agreed to make it a WG draft to be confirmed on the list.
Ron will post email asking if objections to making it a WG draft.


09:40-10:00 M. Napiera - draft-mnapierala-mvpn-part-reqt
Maria was not present to present the draft. No substitutes identified so draft presentation postponed for now.

10:00-10:30 B. Davies - draft-davie-tsvwg-rsvp-l3vpn
bruce presented slides...
need to determine the wg for the draft tsvwg or l3vpn
problem addmission control desired on ce-pe links of l3vpns
running rsvp across these links presents issues
need to associate rsvp with vrf context
need to intercept path messages at egress pe but router alert IP option not visible
may also wish to do admission control across backbone.
need inter AS operation and make sure admission control works in all cases.  This is where work on draft was.

problem to solve is when Path or Resv received at PE which VRF should be operating in.
P routers need to stay uninvolved. Messages must be transparently passed.

A fair number have read a version of the draft.
New objects placed in RSVP messages in service provider network to allow routers to figure out which VRF they apply to.
normally PATH message sent to end point, but instead sent directly to next router so that router alert processing not needed.
can use 4804 for admission control over provider backbones

Inter AS operation - in most recent version of the draft
Option A - just works ASBRs operate like PEs, two separate networks implement solution all information on the links.
Option C - just works  using a PE to PE LSP ASBRs in the middle transparent to RSVP.  If need to do ad control  across backbone then use TE tunnel accross
Option B - all heavy lifing here.  requries ASBRs to process Pathand resv messages and store state to enable revers fwding of RESV
OK solution if you want to do CAC on ASBR link.  IF no CAC needed then storing state for no benefit.  Will ddress in next draft revision

Also dealt with all messages that weren't PATH or RESV.  Details spelled out in draft.
When no CAC offered to customers don't just throw away RSVP messages, treat as IP data grams

Appendix A added to record rejected approaches so not revisited.  Should eventually be removed.

Open Issues
the VRF_ID  in current draft led to state storage in ASBRs evenif CAC not needed. - solution instead of VRF_ID (used to identify VRF, but needs to be recorded and stored as ASBRs. locally significant)
 use VPNv4 PHOP (globally significant) generated by ingress PE, can use LSP that leads to that VPNv4 address.  Transparent to ASBRs.

A suggestion made (Yakove Rekhter) that Path messages should carry the VPN_v4 address of the path message vs. the VPN label.  They are 1:1 and can forward PATH to destination.

Kumaki et al requested support for RSVP-TE from CEs - authors believe feasible, but not yet done.  Next draft version.

Summary
solution sticks to principle of no changes to 4364.

Authors think that with one more rev, draft would be pretty complete.
Draft will be presented in TSV - they own change control for RSVP.  Where do we go with the draft.  Not as much interest in TSV.
ADs could pursue work in this WG and have TSV review.

Is changing the addressing a change to RSVP?  Yes because changing the objects.

If given the OK to pursue document here would people support making it a WG document?  Question withdrawn
Is there agreement to tackle the problem here?
Agreement to tackle problem
Is there agreement that this document should form the basis for the work?
agreement that this document should form the basis for the work

Concern that changing semantic of session object is significant and shoudl be described before agreeing to wg document.  
Comment noted but does not reflect consensus of room.

Support that most of problems addressed by this is related to L3VPN wg.

Some concern that after a reboot there would be inconsistency between up and downstream and this is an RSVP issue.

Will be presented at TSV tomorrow.
Next draft anticipated in a few weeks.
Call for whether it should be a WG document should be made on the list after that.





10:30-11:00 E. Rosen & R. Aggarwal - draft-ietf-l3vpn-2547bis-mcast
Rahul presented the draft with slides (not uploaded)
Some technical loose ends presented (see slide 2)

Goal is to take draft to last call before next IETF

Rahul presented changes from previous version (slide 3, 4, 5)

review is encouraged particularly from those familiar with 2547 and multicast
Maria met with Rahul to address her issues from the last meeting.  Attempts have been made to accomodate her comments in the current draft.
Further discussions with Maria to examine the requirement that this be transparent to the customer to address move from FR, ATM to IPVPN.


Chair's note: too few folks are looking at drafts.  The chair asked for volunteers to review and offer objective, 
constructive techncial comments to the WG.

Dimitri P.
John Drake
Bruce Davie

There are implementations, so this work has not been done in a vacuum.  The work should not be given any special 
treatment.  However, if there is a last call and there are few comments and it looks like it has not had 
adequate review, it is appropriate for the chairs to ask for volunteers to explicitly review the work.


11:00-11:30 E. Rosen - draft-rosen-l3vpn-mvpn-profiles-00

MPVN profiles
The framework allows many choices at different layers by design.
Not desireable to reduce the set of options to one set and no consensus
But - no vendor wants to implement all combinations of options

Need to define profiles to group options that make sense and can be implemented as a set for a particular applciations

reducing the options forces once size fits all, not enough experience to show one set is enough and no consensus

Eric gave brief rationale for including PIM 
Briefly overview of potential BGP for multicast risks

In the draft there is focus on PIM+GRE and PIM+MPLS
Legacy subprofile addresses prestandard from 1999 that doesn't exactly conform to existing set of documents.  
PIM+GRE gives interop with deployed base and helps move deployment to standards(???)

PIM+GRE Profile
Legacy does not support MPLS data plane.  

PIM+MPLS profile 
based on MP to MP LSPs for data and conrol packet.  

Draft currently an individual draft to be pursued as Informational RFC after WG documents go to RFC.
Does the group want to adopt profiles and stnadardize some?

Discussion

One participant wants a mandatory set of options in solutions draft and then profile others.  Profiles long winded.
Mark T.  Progressing after may not be timely to give this work to the IESG.  Also need an applicability statement 
for each profile to say why and where the profile is applicable.  Either have one mandatory set or have more than one
mandatory set and position them.

What is the diff between a BCP and a profile.  A BCP has IETF consensus and informational document does not.

Participant (T. Morin) should use profile approach as last step. 

(Eric) Don't want to turn this into a PIM vs. BGP because still not clear which is right.  Was debated in the past.  Not enough facts
because not enough deployments.

There is a document (T. Morin) written by services providers to capture requirements that has been accepted by WG.   
A contribution by any service provider to add to it is welcome.

Does this document compete with the Morin document?  The Morin document tries to achieve a single mandatory profile, 
this one does not

The requirements should be added to the Morin document
This document is more than a profile, it has protocol spec that is non standard and should not be called a profile or 
profile should be defined.
For informational document it is valid to document protocols used rather than leave them up in the air.

Concerned that there was some misleading information concerning PIM LAN procedures.  It was countered that there are 
no PIM LAN procedures but rather PIM is used in a different way on a LAN.

For many building blocks there is one solution. There should be one set of mandatory procedures 
in the framework, but should not exclude other procedures.

Unicast 2547 does not have profiles why do we have them for multicast.
Multicast deployment predates the standards by a few years and is more complicated than unicast.

Do we want to forward the framework document with options and then profile it?
or do we want to define a mandatory set of options and forget the profiles?
WG must decide.  It was countered that even with a set of mandatory options profiles 
will be needed to define what makes sense of the others.

It was felt that the authors are using the profiles to document their pre-standard implementation.

Let the architecture draft reflect the services provider consensus.

WG needs to decide if one mandatory profile or multiple, if multiple need text to show tradeoffs.

Mark T proposed if the Morin draft describes the mandatory profile then the profile work needs to be folded into it.
A home needs to be found for the additional protocol spec.  It can be found after the standards are done.
The work needs to be done for the pros and cons of the different profiles so the working group can make a decision.

AP Morin draft question to the WG to adopt as a WG doc
AP two volunteers to review document
 
Meeting was adjourned.