Subject: IETF 57 L3VPN Minutes

From: Ron Bonica <[email-masked]>
Date: Tue, 22 Jul 2003 12:57:36 -0400

Folks,

Please review these minutes. If there are no objections, I will post them to
the record one week from today.

                                                  Ron

=====================

PPVPN L3 PPVPN
--------------

July 16, 2003 -- 1300-1500
IETF 57 -- Vienna, Austria
 Chairs: Ron Bonica & Ross Callon

Mintes Recorded By: Danny McPherson and Adrian Farrell

--------------------------------------------------------
Agenda Bashing (no comments)

Alex Zinin: Comments on PPVPN WG Split (to L2VPN & L3VPN)

 o PPVPN will be shut down after draft relocation
 o Thomas Narten will be responsible AD for both L2VPN & L3VPN
 o Rick Wilder, Loa Andersson & Vach Kompella are L2VPN Chairs
 o Rick Wilder, Ross Callon & Ron Bonica are L3VPN Chairs
 o Subscribe to new mailing lists, ppvpn@ will be closed

--------------------------------------------------------
Thomas Narten: Comments from AD, co-AD is Margaret Wasserman

 o Group split and move to Internet Area to couple all related
   technologies in same area.  PWE3 still in

--------------------------------------------------------
Ron Bonica: Charter Stuff

 WG Documents/Chartered:
  - Requirements & Framework
  - Security Framework
  - Three Specific Solutions
  - MIBs
  - Alternative Encaps

  o Out of Charter: Multicast & QoS.  Hold off on submitting work until in
charter.

  o Group does not specify protocols
  o [Others I missed]

--------------------------------------------------------
Ross Callon:  Document Status

 o L3VPN Framework has been approved by IESG for publication
 o L3 Service Requirements passed WG LC but terminology issues and alignment
in progress
 o Generic Requirements updated to resolve IESG comments, letter on IESG
comment resolution on way to IESG

 o Work on Security Framework needs to happen
 o IESG would like security of each approach, work ongoing

 o Applicability statements.
  - VR: Recent Updates
  - BGP IP VPNS:
  - CE/IPSEC

 o Issues on Applicability Guidlines?

  - What is long-term disposition?
  - Should there be seperate L2 & L3 documents or should they stay together?

 o MIBs & Network Management

  - OAM disucssion to follow
  - Textual Conventions: Stable
  - MPLS/BGP MIB: Stable
  - VR MIB: Recent Update for Clarity
  - Requirements for MPLS MIBs: comments to authors of different MIBs
  - CE MIB: TBD.

 o Other WG Documents

  - 2547 for IPv6: Stable
  - PE-PE IPSEC for 2547: Stable
  - PE-PE GRE or IP for 2547: Stable
  - BGP as Auto-Discovery: Stable

 - OSPF as PE/CE re-issued in June
 - [missed one]

--------------------------------------------------------
Luyuan Fang: PPVPN Security Framework Document

 o Motivation: Security FW needs to be defined to progress other WG items
 o Initiated in Atlanta @IETF 55
 o In security area already have well-defined user requirements
 o Need to provide secure VPN services to users, must protect network &
subscribers
 o Defined templates to analyze security properties of different VPN
solutions

 Status:
  - Started in ATL @IETF55
  - Presented first work in San Francisco
  - Collecting feedback on mailing list
  - -01 draft currently published, close to final form
  - Filled in "Section 8"

 Outline:
  1) Intro
  2) PPVPN Security Reference Model
  3) Security Threats
  4) Defensive Techniques
  5) Monitoring, Detection & Reporting of Security
  6) User Security Requirements
  7) Provider Security Requirements
  8) Templates

  - Not meant to address every requirement
  - Every technology need not satisfy every requirement
  - Not in scope of draft to address individual technologies

  - Section 8 on templates: to assit in evaluating and summarizing

  - Would like feedback on document!
  - Ask to move draft to WG document
  - Get feedback from Security WG

Dave McDysan: We have Security requirements, Generic Requirements and
L3-specific requirements.  This document may delay publication of other
documents -- which may be a good thing!

Ron Bonica: Comments in next two weeks.  Luyuang needs to collect input from
other sources.  Publish new version and send to WG LC to avoid log-jam and
chance

Paul Hoffman: Should section 8 be full of templates or?  Need to be
clear this and other documents must be read to get all information that's
needed.

Ron Bonica:  We'll adopt as WG document and see new spin in a few weeks.
Wait on new revision of document and then do WG LC.

Chair: Asked for show of hands for support of document, lots of hands.
No one opposed.
--------------------------------------------------------

Thomas Nadeau: Proposed PPVPN Management Framework

 o Starting point was draft-yacine-ppvpn-mgt-framework00.txt
 o Cleaned up and aligned since last meeting to align with goals
   and requirements of WG.

 o Need to add overall MIB architecture and view much like MPLS

 o Need to talk more about customer managment
 o Service OAM (OAM for VPN and interactions with VPN substrate)
 o Consider renaming to Framework for VPN OAM
 o Get more WG input

 o Question: Consider as WG draft (may be charter issues)

Ross Callon: Alex Zinin says it's fine if we accept as WG document.
We can go to IESG to get charter updated to get the document as WG
document.

Chair: Asked for show of hands for support of documents, lots of hands
go up.  No one opposed.

--------------------------------------------------------
Rahul Aggarwal:

 o Mechanism for signaling PE tunnel encap capabilities.

 Motivations:

 o Blackhole Avoidance
 o Co-existing MPLS & IP encap

 BGP Tunnel Capability SAFI
 LDP Tunnel Encap Capabilities (may not be necessary per BGP)
 IANA Considerations

Request to be a WG document in L3 VPN WG.

AD (Alex Zinin): If L3 VPN supports IDR needs to do technical
review.  Doesn't believe that document can become a WG document
per BGP changes.  Needs to verify if this is real problem, then
choice of moving whole draft to IDR or splitting document into
separate drafts.

Rahul: What is procedure for extensions?

(AD) Alex Zinin: Protocol-specific procedures go to protocol WG.

Rahul Aggarwal: What is procedure for extensions?

(AD) Thomas Narten: If this is real problem then qualify on mailing list
and then we'll go from there.

How many people have read the document?  Lots of hands go up?
How many people think this is a valid problem? Lots of hands go up.
How many people think work should not be done?  No hands.

--------------------------------------------------------
Pedro Marques: Constrained VPN Route Distribution

Problem: VPN Route Distribution Layer must carry routes for all VPNs
Goal: Reduce number of routes carried in all RRs by taking advantage
      of locality

Ross Callon: Is this a problem the WG should be concerned about?
Ross Callon: Is this a problem the WG should be concerned about?

Who's read the document?  Modest number.
Who thinks we should be concerned about: modest number
Should this not become a WG document: 1 hand.

Yakov: Protocol Extension.  Lots of interoperable implementations

Pedro: Does not modify existing standard to BGP, but AD/IESG

AD (Thomas Narten): Does this change bits or protocol?

Pedro: No, introduces NEW bits!

Dave Ward: Disagrees, thanks it changes fundamental BGP behavior.

AD (Thomas Narten): Would like to hear from folks who said no to
the problem, why?

WHO?: Problem is that it needs to be done in IDR, not L3 VPN

Pedro: Just here toi ask WG opinion of is problem is real and is
 this is a valid.

AD (Alex Zinin): Will show up in IDR, concentrate on solution
properties here.

George Swallow: Scalability is an issue and always worth tackling.
 As long as proposal is sound in IDR ir should be OK here.

Luyuan Fang: This is a real problem.

--------------------------------------------------------
Pedro Marques: Use IBGP as PE-CE Protocol

Ron Bonica: Is CE device peering with you using AS number is there
restriction
 of him using that AS number with other networks?

Pedro: He only sees his own AS number, doesn't see which AS Paths occur in
 provider network.

Joel Halpren: Looks like useful tool.  IDR should build as
general tool and
 use it for other stuff.  Else IDR says it's crazy and we shouldn't do it.

Pedro: Only relates to 2547, belongs in PPVPN.

WHO?: Why would we run IBGP with a domain we don't control?  How do you
 safeguard IGP/IBGP with this?

Pedro:  No assumption IGP is being run.

Ross Callon: Issue is whether this is useful, where work falls is
  subsequent.

(AD) Alex Zinin: Agress with Ross.

--------------------------------------------------------
Lede Feng: IS-IS as PE-CE Protocol in BGP/MPLS VPN

Motivation: In 2547 lots of PE/CE protocols.  IS-IS not
 defined.
 - In OSPF case lots of drafts
 - No IS-IS draft

Would like to progress as WG document

How many have read this?  (not many hands)

Feng: China Telecom Requests that it be implemented.

Question: Should we only suppory wide-metrics?
Question: Does this support IS-IS Admin tags?

Danny McPherson: Is this being defined for sake of defining it
(i.e., because other protocols have already been defined) or is
this really demand driven?  Are customers really running IS-IS
and considering this for CE-PE protocol?

Request for show of hands for interest in pursuing this work: None

Need to take it to the list.

--------------------------------------------------------
Gargi: Tunnel Encap signaling using Tunnel SAFI

New IPv4-Tunnel SAFI

Comment: Why do we need this?  Also, how do you deal with
>misconfiguration?

Gargi: SAFI signaled to all other PEs in the network.

Comment: Same as Rahul's draft/preso.

Danny McPherson: These are the same problem, two document
authors should work together.

Rahul/Others: Draft authors will work together.

---

From: "lidefeng" <[email-masked]>
Date: Wed, 23 Jul 2003 21:34:20 +0800

About the draft draft-sheng-ppvpn-isis-bgp-mpls-00.txt,I would like clarify something
>Question: Should we only suppory wide-metrics?
This draft supports both narrow-metric and wide-metric,this is clarified in the attached slides

> Question: Does this support IS-IS Admin tags?

This draft doesn't support IS-IS Admin tags for the time being,but in the following version,it can support.

This draft is defined under the requirement of the customer(China Telecom),not defined for the sake of defining it.We hope this draft can be reviewed by some experts,and progress to an informational RFC.

Thanks
Defeng Li