Subject: San Francisco PPVPN WG minutes

From: "Marco Carugi" <[email-masked]>
Date: Mon, 31 Mar 2003 18:16:25 +0200

All, 
below the minutes of our SF meeting - recorded by Ananth (thanks !!) with
some changes/additions by myself.
Please comment before the end of this week.

Meeting presentations (some are still missing)  will be available in one/two
days on the informal PPVPN server at 
http://standards.nortelnetworks.com/ppvpn/calendar.htm (SF area)

Thanks, Marco 

----------------------------------------------------------------------------
---------------------
PPVPN meeting - 56th IETF - March 19, 2003 - San Francisco, CA
----------------------------------------------------------------------------
---------------------

Minutes recorded by Ananth Nagarajan, some changes/additions by Marco Carugi

1. Marco - Agenda bashing and WG status
--------------------------------------------------------------
Marco started with agenda bashing, then gave a status report of the WG.  
The layer 3 requirements and framework drafts have been submitted to the
IESG for consideration as Informational RFCs.  
The next step is to have WG last calls for the candidate L3 approaches
before submission to IESG (2547bis and VR) for proposed standard in a few
weeks.  Complementary documents will follow this.
Corresponding L2 documents would be progressed in the next months before the
July meeting.

The L3 framework and requirements documents received comments from IESG.
The generic requirements draft also needs resolution of comments of IESG.
All these drafts would be sent back to IESG in few days.
Draft-ietf-ppvpn-ce-based draft will be discontinued as part of it has been
integrated in L3 framework, other part in
draft-declercq-ppvpn-ce-based-sol-00.
WG last call of CE-based IPSec VPN solution ID is targeted before next IETF.

Effective progress of the applicability statement guidelines draft is not
clear, discussion is needed.
The terminology draft and first l2 solution documents will be moved to WG
soon after the meeting. 
The metrics draft will be discontinued (proposal of the L2 team, agreed by
AD too), the L2 reqts draft becoming the single basic reference for
solutions.
The L2 requirements document (L2 team product) needs wider review by the
whole WG.  The l2 Framework document is in good shape. Both these documents
are  being targeted for IESG submission in the April-May  2003 timeframe.  
There are currently no WG documents in the L2 solution space.

All design teams, except the L2 design team, have basically concluded their
tasks. The L2 team will be closed now, although the team list will continue
to live until completion of L2 reqts and L2 framework documents.

Marco gave an update on L2 design team discussions.  The functional
decomposition recommended in Atlanta aimed to complete a set of functional
documents,  whose initial content was produced by 4 team members for the
interim meeting in Billerica - January 2003.  The result of discussions in
Billerica (Scott attended too) was to discontinue the work on functional
decomposition. Other meeting outcome : solutions documents will have to
include a requirements compliance section; design team will not recommend
any specific solution ID to the WG, discussions and decisions will be made
based on mailing list input. Most of (not all) team members favoured the
progress of the L2 solution documents as experimental, and not standard
track, for now, but this needs to be discussed further by the whole WG.  
The status as of now for L2 documents is that the optional template has not
been widely adopted, few solution IDs contain the reqts compliance section,
WG list discussion on various solutions has not happened yet. Wide
participation of WG is requested to progress this work soon, by selecting a
number of solutions  documents in L2 space (need that authors update their
solution IDs with reqts compliance section, and start discussion on their
document on the list).  Current milestones indicate L2 solutions submission
to IESG in June, but it will require confirmation (Applicability Statements
and MIBs work has not started yet).

There is a clear need to have strict relationships with protocol specific
WGs for protocol extensions in PPVPN.  To evaluate the interest of
requesting  rechartering of the PPVPN WG at a certain point in time to
remove the restriction on protocol development.

Alex: Clarified that there is no current intention to take the work of other
WGs on protocol deployment and do it in PPVPN.

Francois: Didn't mention IPv6 VPN document that is a WG document. Checking
if the status has changed.
Marco - No. Draft not mentioned explicitly for brevity, but it is in.

Further work to be done in PPVPN in terms of QoS, security and management
frameworks : WG input is needed to focus areas of development. 
L2 interworking and service OAM were brought up for discussion in the L2
team: Marco's proposals in this meeting on such items need to be discussed
on the list.
Other topics for future discussion include multicast, l1/optical VPN and
wireless VPN. 

Alex: There is a lot of work that PPVPN needs to do, that it has not
finished. So let us not extend the charter.
Marco: It's agreed that multicast, l1/optical VPN and wireless VPN are not
WG items for now.
-----

2. Jeremy DeClercq - CE-based L3 PPVPN progress
----------------------------------------------------------------------------

Jeremy gave an update on the CE-based L3 space.
draft-declercq-ppvpn-ce-based-sol-00 is proposed as PPVPN CE-based IPSec
solution document.  Draft-ietf-ppvpn-ce-based will be discontinued and kept
for reference only. 

Clarifications on management responsibility, routing realms and Internet
access, auto-discovery were made. Future steps include making this a WG
document and  progressing the corresponding AS document.

Joe Touch: We have running code that is similar to this draft, except it is
push-based, and not pull-based. Also it has not been cited as reference. 90%
is  similar to this document, 10 % is different. We have running code.
Jeremy : It will be discussed.
Alex Zinin : Is there consensus on the 10% difference? Running code is not
enough, need to come to the WG and ask for consensus.
Joe Touch: Also need to read prior work and cite reference.

Dimitri: What is meant by "what to do with draft-ietf-ppvpn-ce-based?"
Jeremy: Parts of this document were moved to L3 framework document. The
solution specific part has been taken into
draft-declercq-ppvpn-ce-based-sol-00.

-----

3. Robert Jaksa - Hierarchy of Provider Edge Devices in BGP/MPLS VPN
----------------------------------------------------------------------------
------------------------------

Robert Jaksa described the need for Hierarchy of Provider Edge (HoPE) for
better scalability of PEs in RFC2547bis, and discussions that came up in the
mailing list on this draft.

Eric: Not exhibited any case of lack of interoperability at protocol level
with 2547bis. You have only exhibited a deployment model. So it needs no
consensus  and should not be discussed here.
Marco: I agree with Eric, draft doesn't seem to have protocol impact. Need
to see now which is support from SPs and debate on the list on possible
protocol  impacts. Further, we could evaluate interest in progress as
informational.

Rahul: If people want to do this on 2547bis, pass a default route between CE
and PE. This is deployment issue, and shouldn't be taken up by WG.

----
4. Michael Behringer - MPLS VPN Import/Export Verification
----------------------------------------------------------------------------
------------

This draft addresses Route Target misconfiguration prevention for 2547bis.
Ron Bonica's draft was compared. Michael's draft does not require CE to
participate, and does not allow verification by site, and requires routing
from  CE-PE. Not sure how sensible this is.

??: this is to prevent misconfiguration by SP. Is this enough justification
to do this work?
Michael - agree

Alex: asked technical questions on the draft. Admitted he needs to read the
draft to clarify.

Marco: We should work with Bonica draft and security framework team. Also
look for solutions that are not specific to 2547bis.

??: The potential attraction is to not require change on CEs. It may not be
the best solution, but it is a viable solution.

-----
5. Vach Kompella - VPLS draft (draft-lasserre-vkompella)
----------------------------------------------------------------------------
------

Vach discussed the history and recent updates on this draft.  He also
mentioned that there are live deployments and several trials,
interoperability between  6 vendors.  Request this to be a WG draft (been
around long enough)

Marco: extensive debate should be on mailing list. Support can be registered
here, but to be considered that not all of the solutions drafts have a slot
in agenda today.
Vach: Didn't ask the other guys not to present at the meeting.

Rahul: Why did VC type change?
Vach: To show that behavior of pseudo wire is the same as the ethernet
pseudo wire. Continue to discuss on mailing list. May be FEC type.
Juha: Use application ID in L2TP.
Vach: It's the same as that, but doesn't do L2TP.

Eric: this is an MPLS specific solution.  Could generalize several things.
the fact that it  has been around 2 years, and not been done yet.
Vach: Should we not have a separate l2tp specific document?
Eric: Doesn't make sense to have 2 documents that are 90% the same.
Vach: propose to use a generic VPN ID TLV, instead of using VC ID. It is not
fair to say we haven't considered this. We need a wider audience to
participate.
Marco: This further shows the need to discuss this on the list.  But don't
prolong the discussion too much.

Alex: For a document to become a WG draft, it doesn't have to be 100%
correct.  It can become a WG document if it is a good start.
Matt: I wanted to make the same comment.
Rahul: to carry on what Eric said, the arguments should be applied to the
entire L2 space  (autodiscovery etc.).
Marco: that's actually why functional documents were recommended in Atlanta.
Rahul: I don't want functional documents, want it as a piece of solutions
documents.
Marco: If people commit this work within a targeted time, let's have it. 
Alex: When a document becomes a WG draft, it should be easier to have
authors introduce changes to it.  Because once it becomes a WG draft, the
author  becomes an editor.

Marco: asked for show of hands to make this a wG draft.
Strong interest was shown in room. Further discussion on the list. 

Vach informed having some overview slides on last ISOCORE Interoperability
tests (Rajiv Papneja) : Will be submitted later for discussion on the list.

----
6. Vasile Radoaca - GVPLS/LPE
-----------------------------------------------

Vasile described the history of this document, and explained the
characteristics of the GVPLS model. Future steps include convergence with
rosen signaling  document, integrate qos and resiliency, enhance oam
capabilities, convergence with vpls.

Rahul: want to clarify if this is not in opposition to the hierarchical VPLS
text in Eric's document.
Vasile: Convergence can be done pretty easily.

Ali: Given that you use two sets of pseudowire, there is a chance of packet
reordering. Would like to see some discussion on that.

-----
7. Cheng-Yin Lee - Hybrid Virtual Private LAN
-----------------------------------------------------------------

Cheng-Yin described the draft.

Ali: pseudowire doesn't have bridging.
Cheng Yin: CLE can consider one VPL. Use spanning tree across core.
Ali: Scalability of spanning tree over SP core is an issue.

Eric: This should not be taken up.
Cheng Yin: more scalable appproach.
Marco: take it to the list.

-----
8. Juha Heinanen - Radius-based  Discovery
----------------------------------------------------------------

Motivation - BGP-free VPN discovery and Wide support for RADIUS in current
equipment.
This also works in multi-provider cases.  Juha explained the working of
Radius-based discovery.

Juha: IS there interest in working on this. would need co-authors.
Room showed great interest.

----

9. Experimental vs standard track discussion
-----------------------------------------------------------------

Marco: For l2 solutions, how many people support them being proposed as
experimental solutions (to allow deployment and feedback from the field).
Just recall  that most of team members (team includes the authors of main
solution drafts) favoured the experimental option, but the whole WG has to
express his view. To also note that one essential difference between
experimental and standard track is that experimental docs cannot be
normative references. 

Vach: As I remember, if there is no consensus around a particular solution,
then take the solutions that are gaining momentum and make them
experimental.  If  there is only one solution, no point in making that
experimental.
Alex: No such thing as a "design team decision".  This should be taken up
with the WG.
Marco : Agreed. WG discussion is requested for this reason. 
Kireeti: I'd like to disagree with my brother :-). (Ananth's note : but went
on to  say the same thing as Vach said).
Eric : That's been the problem with the design team. We come to some
consensus within the DT, and then people individually remember differently.

Alex : Requirements for experimental RFCs are clear in RFC 2026. I'd like to
move forward with this and want to resolve it before next meeting. If this
means  an interim meeting of wG, let's do it.
Kireeti: Agree with Eric on disagreement of Design Team. So let's pretend
the Design team never happened.  So let's run the idea of experimental by
the WG,  and progress all as experimental. Wait for some time to see which
become adopted (2 or 3).
Vach: The point of "not remembering that the design team decided this" was
to exactly bring home the issue that there is disagreement within design
team.  So  to reiterate, let's see if there is consensus on one approach,
else we can have experimental.
Alex: One missing point is that the WG should decide this.
Marco: discussion on the list.

-----
Time ran over and other presentations were continued beyond 1500 hrs (good
attendance) 

10. Fabio Chiussi - PPVPN QoS Framework (draft-chiussi and draft-declercq)
----------------------------------------------------------------------------
-----------------------------------

Fabio described changes and updates on draft-chiussi. Content still needs to
be refocused, reorganized and expanded.
The next steps are to make the draft more readable (short), merge with
draft-declercq-ppvpn-l3vpn-qos, address ppvpn-specific restoration, inter-AS
QoS etc.

Fabio went ahead and presented Jeremy's draft. The goal of both drafts after
merging is to have a PPVPN QoS framework reference document for other QoS
drafts  defining solutions/QoS signaling extensions, QoS MIBs, etc.

Mustafa Aissaoui: question about combining of 2 drafts, because the first
draft talked about issues and guidelines for QoS, while Jeremy's draft
separates  guidelines from issues.
Fabio: The merge plan is to keep the guidelines section, and the framework
to be merged with Jeremy's draft (keep best of both).

Dave McDysan: where does QoS framework document fit in charter? Propose
merging necessary material in solutions documents. 
Marco : One of the issues with merging into existing basic solution
documents (L3 solutions drafts) is the issue of extending the documents and
therefore  affect timeline. But we need to have WG's view on the list.   

----

11. Luyuan Fang - Security Framework for PPVPN 
-------------------------------------------------------------------------

Luyuan presented the draft and said Jeremy would be added to the authors'
team in the next version. Luyuan described that there were different
security  levels expected in different PPVPN services. Therefore this
framework gives guidelines for different implementation technologies.

Ananth - suggest adding requirements to generic requirement draft and have
the security features of each approach be described in applicability
statements.

---
Marco: we need to close here. Basic objective of presentations on frameworks
was to stimulate input from the WG, to be continued on the list. All
presentations will be available on the PPVPN informal server.