Subject: Atlanta PPVPN minutes

From: "Marco Carugi" <[email-masked]>
Date: Wed, 4 Dec 2002 13:08:28 +0100

All,  
Atlanta PPVPN WG minutes follow. Thanks to Ananth. 
Please comment on the minutes before Dec 13 so that we can make the required
corrections and send them to IETF proceedings. 
These  minutes and all meeting presentations (including my WG status and two
presentations not given for lack of  time),   will be available within
tomorrow on the informal PPVPN page
http://standards.nortelnetworks.com/ppvpn/calendar.htm 

Marco

****************************************************************************
*******************************************************
PPVPN WG meeting at 55th IETF, Atlanta, GA - Nov 20, 2002

Minutes recorded by Ananth Nagarajan  (few additions/changes by  Marco
Carugi)

Marco started with introducing the agenda. Meeting related documents will be

posted on Nortel-maintained web site.

1. WG status
------------

Milestones have been recently updated. Layer 3 reqts and framework have been

submitted to IESG. We are now at second round of comments, before they move 
towards Informational RFC.

L3 approaches and applicability statements : submission to IESG for 
publication will be hopefully started in December.

Marco also described the status of various documents (these updates have 
been sent to the mailing list).

Last call on draft-ietf-ppvpn-cl-tunneling-vpn-00.txt not successful. 
Solicited input on whether this should be progressed in the WG. Little 
support, but most didn't care.

Scott - Lack of strong opposition does not mean support.

Under WG consideration - generic requirements, l2vpn requirements, vpn
DNS-based
discovery documents, terminology and metrics.

Kireeti - Move to WG - does it mean that it is moved to WG status? If so, it

needs call for consensus.
Marco - yes, the normal process will be followed.

Scott - CL tunneling:  Is there support for publishing this as a 
informational RFC, as opposed to BCP? ASk for consensus on BCP RFC, Info RFC

or is against publication?
Yakov - BCP means best current practice. Since it is neither, there should 
be no such option.
Scott - Disagreed.

Consensus - support from authors for info RFC. None for BCP. About 10 people

against publication. A lot of agnostics.
Decision - need more discussion on mailing list.

Scott - IESG has enough info to take this off the WG agenda.

WG last call for draft-nagarajan-ppvpn-generic-reqts after it becomes a WG 
ID, to be done by end of 2002.

Conditional to IESG approval of L3 reqts and framework, 2547bis and VR 
approaches to be advanced to Proposed standard.  Protocol dependencies to be
solved and submitted in parallel, together with applicability statements.

Other 2547-based solution documents, VR extensions, L3 solution-specific 
MIBs etc will be advanced in reasonable timing.

CE-based IPsec solution has not been updated since Yokohama, along with 
corresponding AS.  Would like to progress this quickly.

Design teams:
Requirements team task on generic requirements and improvement of L3 and L2 
requirements is being done.

Some issues: Cooperation terms with IEEE 802.1 need to be figured out. 
Interaction with related WGs in IETF needs to be done for PPVPN,
independently
from whether sub-ip area survives or not.  Layer 2 interworking for 
like-to-like is ok, while any-to-any is not currently ok (out of scope),
apart from possible specific scenarios.

Other work to be progressed includes QoS, management, security framework, 
multicast etc. for PPVPNs. Input from community is solicited.

Liaison received from ITU-T on L1 VPNs was discussed.

2. Generic Requirements - Ananth Nagarajan
-------------------------------------------

Ananth described the generic requirements draft and solicited input, 
especially for the scalability section.  Loa talked about the terminology 
draft that is being simultaneously developed.  There was a word of caution 
on the way this terminology draft would be progressed separately, as it 
would create problems for proposed solutions if they don't comply wih this.

Request acceptance of generic requirements as WG draft. 
General consensus was for this acceptance.

3. CE-CE Authentication - Ron Bonica
-----------------------------------

Ron made a short presentation on main issues related to this work.

Process considerations - need BGP extended community type. Need UDP port 
number for new protocol.
Vach expressed a procedural concern about whether PPVPN can do protocols.

4. CE autoconfiguration for CE-based PPVPN - Cheng Yin Lee
----------------------------------------------------------

Cheng Yin described the draft.

Issues - is being able to push/update necessary? Is polling sufficient? 
Combining polling with receive-trigger-then-pull or push approach may be a 
good compromise (may then reduce polling interval)?

5. IPsec protected Virtual Links for PPVPNs - Mark Duffy
--------------------------------------------------------

Virtual Link - point to point link across IP network implemented via 
tunneling. This is envisioned for CE-based and PE-based vR solutions. This 
can also be done between CE and PE.  It is also useful for 2547, and hybrid 
networks for securing links between PEs running 2547 and VR.

Requirements - multi-context support (multiple virtual links between a given

pair of systems).

Eric - Does it make sense to have one security association for all vpns, as 
opposed to separate associations for different vpns.
Mark - Yes.

Why this is needed? Current efforts don't address the multi context needs of

network based VPNs.
Issues : How does IPsec policy fit where forwarding decisions are made by 
best-matched prefix?  How should VPN-ID like context be conveyed when a 
tunnel is established.

Draft describes various approaches using combinations of either IPsec tunnel

mode or IPsec transport mode with other tunneling schemes.

Applicability to ppvpn - standards-based virtual links for adequate security

for interoperability between approaches.

Eric - There is already a draft on IPsec with 2547. Why is this different?
Mark - this is not objecting to that draft, but that is specific to 2547 
context. This is more generic.

Marco - Is this mandatory before progressing VR? Or is it complementary?
Mark - There is no mechanism defined today for securing VR tunnels. If you 
simply say "use IPsec tunneling between VRs", everyone will be doing it in a

different way.

Marco - Need further discussion on this.
Mark - There is no alternative available in current drafts.

Yu-cheng Ren (ISI) - This topic has been addressed by various drafts.  Why 
do we need another (e.g. draft-touch, draft-knight).
Mark - these drafts talk about using ipsec tunnels, but doesn't talk about 
securing multiple links.
One of the authors of draft-touch - this is not the case. It talks about 
ip-in-ip draft.
Yu-cheng - Nothing against this draft. Can this not be integrated into 
framework or requirements drafts?
Mark - some part of this can be added. Need discussion on what needs to be 
included.

6. Use of multiple instance OSPF for PE-CE - Kunihiro Ishiguro
--------------------------------------------------------------

Kunihiro presented this draft - "simple way to use ospf for ce-pe".
Procedure - Assign OSPF instance to VRF.

Benefit - much simpler, can coexist with ospf configurations, and can be 
applied to is-is.

This draft complements Rosen draft (draft-rosen-vpns-ospf-bgp-mpls-05.txt) 
and overlaps a little bit.

Eric - Don't need different procedures to do the same thing. Hoped this 
would eliminate complicated things in existing mechanisms.

7. L2 VPN design team report - Loa Andersson and others
---------------------------------------------

Documents - metrics, terminology, framework (not much work done on these 
three). L2vpn requirements - significant progress. There was a design team 
debate on emulated LANs versus bridges.

The design team has 22 members, plus several others who contributed that are

not on the team.  Recommend that design team structure be discontinued and 
work be continued separately.

Requirements - Yetik Serbest
------------

Status - evolving towards common l2vpn requirements (as opposed to 
individual requirements for vpws, vpls etc.)
Aligned with generic requirements draft, definitions moved to terminology 
draft, sections added on referencing generic reqts, addressing, network 
resource partitioning/sharing, access control, interoperability.

Future work - clarify any issues with what a vpls is, and what it does, and 
clarify vlans in vpls.  Also request feedback.

Request moving it to WG status.

Loa: The document has a "point-to-multipoint" VPWS, which is wrong and needs

to be removed.
A: Agreed.

Cheng Yin: Is VPLS emulating a bridge or LAN?
Yetik - wait for Eric's presentation.

Architectural Model - Eric Rosen
--------------------------------

Eric described the architectural model, and addressed points of disagreement

between IETF and IEEE people, and inter-relationships between VPLS and IEEE 
bridge/LAN emulation.

Other issues - Spanning tree, presumed LAN properties including packet order

preservation, reliability, non-duplication, low latency.

Loa - Nice powerpointing picture will be converted to ASCII art and used in 
requirements and framework drafts.

Issues of VPLS - Muneyoshi Suzuki
---------------------------------
Muneyoshi discussed issues related to customer views, provider views, vpls 
support etc, routing for LAN/bridge emulation.

Norm Finn - IEEE 802.1 unofficial liaison
-----------------------------------------

Project authorization request (amendment to 802.1q VLANs) - enable a SP to 
offer the equivalent of separate LAN segments, bridged or virtual bridged 
LANs (network of bridges doing l2vpn type services).

Name of project - 802.1AD.
MAC-in-MAC not possible with this amendment.

Confident that IETF L2vpn and 802.1AD will be interoperable, compatible etc 
if mailing discussions are carried through.

Q: how to solve MTU in 802.3 problem?
A: Make it longer. This is possible.

Cheng Yin - There should be minimum of overlap with vpls and IEEE work.  But

there will be overlap as IEEE defines Q-in-Q and IETF defines other 
encapsulation.
A: Outer Q tag can be used as Pseudowire header. So there won't be a 
problem.
This is exactly VPLS - just a different way of looking at it.

Marco - intention from both sides to minimize overlap.

Vach - there is no standard q-in-q way to identify customer packets.  What 
the IEEE is doing in standardizing this may be a good thing.

8. CE-based Virtual PRivate LAN - Cheng Yin LEe
----------------------------------------------

Previous version described use of l2tpv3 for this application. l2tpv3 
signaling and tunneling will be taken to l2tpext WG.

This model describes the transport of Ethernet over IP tunnels (CE-based).

Future work includes failure scenarios, monitoring of vpl connectivity and 
other l2tpv3 specifications to be done in l2tpext WG.

Eric Rosen - Why not IPsec as it is CE-based?  Why do use l2tpv3?
Cheng Yin - No protocol number for use of ipsec.

9. Identify PW endpoints signaling - Eric Rosen
-----------------------------------------------

It is possible that PWE3 owns the signaling portion. l2vpn can be built over

pwe3 pseudowires.

Problem statement: L2vpn has various autodiscovery. Martini signaling 
presupposed provisioning models. This solution identifies ways to use 
martini signaling and make it more applicable to l2vpn.

Forwarders will be identified by vpn-id.

Eric described various techniques (e.g. Distributed VPLS, VPWS full mesh, 
switched connection i.e., ATM SVCs to pseudowires).

RAhul Aggarwal - Support this as it solves real issues with martini 
approaches.
Marco - need clarification from ADs about this space, and where this needs 
to be done.
Eric - Some of these also apply to l2tp signaling, in addition to martini

Yakov - Can you use other forms of identification instead of VPN-ID
Eric - yes.
Hamid - suggested to use global unique identifiers instead of VPN-IDs
Marco - Global ID issues need to be taken to list.

10. Scalability issues with VPLS - Andrew Sodder
------------------------------------------------
This draft has various parts, one part belonging to ieee (mac in mac), other

parts to ietf.
The draft also proposes vpn identifier and control word use.

Many issues left to be addressed - vpls interoperabilty, oam ID work to be 
done in IEEE.

Request continued discussion on list.

Rahul Aggarwal - Don't understand motivation for the draft. There is no 
scaling issue with current mechanisms. This draft request changes to wire 
format, and requires changes to hardware.
A: Depends on who you talk to.
Rahul: Depends on which specific vendor box you are talking about.

11. GVPLS/LPE - Dinesh Mohan 
-----------------------------
Goal - support seamless integration of both distributed and non-distributed 
vpls models. Allow integration of different access topologies, in a 
hierarchical way.
Other objectives - scalability and performance, optimizaton of replication 
and support for multicast applications, interoperability with other vpls 
solutions, integrated oam capability in data plane.

The complementary draft-chen-ppvpn-dvpls-compare-01.txt describes
comparisons of vpls 
approaches. Andersson's metrics draft was also mentioned.

Future steps - convergence with solutions drafts, signaling, QoS/resiliency,

enhance oam capabilities.

Marco - comparison draft and metrics draft should be used by the design 
team.

12. VPLS based on IP multicast - Ali Sajassi
----------------------------------------------

Multicast, if supported on backbone, can be leveraged for vpls.
mp2p PW for unicast and mp2mp PW for multicast is proposed.

Encapsulation is GRE or l2tpv3. pw signaling is not needed.
Issues - packet reordering may occur.  Inter AS and IP address management.

Sasha Vainshtein - PPVPN scalability parameters in requirements draft not 
enough for feasability of this draft. Also, all routers in provider core 
would need to learn routes to all these addresses.  Text of the draft 
doesn't say how unicast addresses are treated by the device (pingable, or 
something else).
A: RFC 1918 specifies private address space. This scheme can be used in 
hierarchical way (access, core etc.) and thus may tackle scaling issues. 
Regarding router issues, these can be taken to the list.

Eric - VPLS depending on IP multicast sounds foolish.  learning based on 
source address is also not a good idea (fragile).
A: Discussion on list

Juha - One of the requirements is operability in multi provider environment.

  Multicast may not be stable in this scenario.  We need to take that 
requirement into account.

13. L2VPN Interworking - Ali Sajassi
-------------------------------------

Local attachment circuit termination proposed for various attachment circuit

types including ATM, ip, ppp, multiprotocol. Need two new PW types for IP 
and multiprotocol.

Rahul - It may be useful to consider the idea of a "raw" pseudowire that can

be used for multiprotocol case.
Ali - wouldn't apply for multiprotocol, as it needs identification of 
protocol.

Scott - Interworking out of scope of, when sub-ip was set up.
Ali - purpose is not to reinvent the wheel. Just suggesting what pseudowire 
to use.
Marco - Scott, should this continue to be discussed in the Working group.
Scott - if it is restated as it was by Ali, it can be done.

14. Summary - Marco
-------------------

In Yokohama, it was agreed to propose solutions based on functional
structure
proposed in L2 solutions design team.  Next work steps on L2 were discussed.

Functional decomposition of l2 is strongly recommended. No protocol
development in 
ppvpn.  Limited set of solutions, so it is not recommended to progress "all 
theoretically possible solutions". So we need to determine a pragmatic set 
of alternatives.

Main functional blocks identified by DT (various options per block)
- discovery, signaling, pw tunneling/data plane forwarding, informational
model.  
Therefore, the functional documents should have a requirements section, 
option specification section(s), a section on interactions with other
functions.

Possible organization of deliverables :
- N documents per each functional block, one per option
- one doc per each functional block (N option-specific sections).

A number of mono-option documents is almost done.

Different solutions using same option for a specific function should rely on

the same functional document.

Aggressive plan for L2 DT is to have a DT meeting in January 2003 (1-2 
days). Tasks to be completed were identified.

It is possible to have another design team (in addition to this one) before 
the next IETF meeting.

****************************************************************************
**********************************************

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 04 Dec 2002 06:26:20 -0800

Marco,

> http://standards.nortelnetworks.com/ppvpn/calendar.htm 

[clipped...]

> 9. Identify PW endpoints signaling - Eric Rosen

Please reflect in the minutes that I asked specifically whether one could 
use the form used by the Route Target BGP Extended Community. 

Yakov.