Subject: FW: IETF 57 L3VPN Minutes

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Jul 2003 11:44:33 -0400

Folks,

If I don't hear any objections, I will register these updated minutes.

                                    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 Farrel
>
> -------------------------------------------------------
> Agenda Bashing (no comments)
>
> Alex Zinin: Comments on PPVPN WG Split (to L2VPN & L3VPN)
>
>  o PPVPN WG 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 Interested participants should subscribe to the new mailing lists
    ([email-masked] and [email-masked]), since the ppvpn mailing list
    will be closed.
>
> --------------------------------------------------------
> Thomas Narten: Comments from AD, co-AD is Margaret Wasserman
>
>
> --------------------------------------------------------
> 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 WG will specify the requirements and application of existing
      protocols for support of L3 VPNs. The WG will not specify
      protocols.
>
>
> --------------------------------------------------------
> 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
   - CE-to-CE member verification: Stable. However, alternate has been
     proposed. Work is needed to compare them.
>
>
> --------------------------------------------------------
> 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 There are well-defined user requirements for VPN security
>  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 Advisor
>
>
> Ron Bonica:
        - The document is important, and is in very good shape.
        - Propose adopt as WG document
        - Would like to ask people to send comments to the l3vpn working
           group within two weeks
        - Luyuan to collect feed back from email list and other sources
        - Luyuan will respin draft in two weeks or so (after first two
weeks)
        - Propose that we then more to WG last call>

> Paul Hoffman:  Should section 8 include completed templates, or only the
  outline for templates. [Reply: The timeframe implies just the
  outline for templates -- he was okay with this.]  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: It is not clear whether this is in our charter. Alex advises
that it
  is okay for us as a working group to decide whether we would like to
accept
  this as a working group document. The chairs can then check with the ADs.
  If a charter update is needed then we can ask the IESG post facto for a
charter
  update.

> 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?
>
> 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: BGP already has protocol extensions. There are lots of
  interoperable implementations. This spec uses what already
  exists in BGP.

>
> 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 to 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 coming from a real problem. The solution proposed
>     by this draft will be very helpful in our Inter-AS VPN implementation.
>
> --------------------------------------------------------
> Pedro Marques: Use IBGP as PE-CE Protocol
>
  Ron Bonica: Does the CE device peer with you using the carriers's
  AS number? If so, then this would seem to have a problem given
  that the carrier would be peering with multiple VPNs.

  Pedro: The CE uses its own AS number. Therefore in this case the
  PE would also use the private network's AS number for exchanging
  I-BGP with CEs from that particular private 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.
>
>
> --------------------------------------------------------
> Li Defeng: 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)
>
> Difeng: China Telecom Requests that it be implemented.
>
>Question: Should we only suppory wide-metrics?
> DifengThis draft supports both narrow-metric and wide-metric,this is
clarified in the attached slides
>
> Question: Does this support IS-IS Admin tags?
> Defeng: This draft doesn't support IS-IS Admin tags for the time being,but
in the following version,it can support.
>
> 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?
>
> Difeng: 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.
>
> 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.
>