Subject: Draft minutes of L2VPN WG meeting @ IETF 66 (Montreal, Quebec, Canada)

From: Shane Amante <[email-masked]>
Date: Sun, 16 Jul 2006 22:46:31 -0600

Draft meeting minutes of the L2VPN WG Session at IETF 66 have been  
posted to the following URL:
http://www3.ietf.org/proceedings/06jul/minutes/l2vpn.txt

Please review and provide corrections no later than Friday,  
8/11/2006, 17:00 EDT (UTC -4).

In addition to the meeting minutes, all of the presentations have  
been uploaded to the following URL:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66

Thanks to Giles Heron, Mohan Nanduri and Mustapha Aissaoui for taking  
notes!

-shane & Vach

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 17 Jul 2006 14:00:58 -0400

I wanted to chime in on the discussion that took place
at the meeting RE: the L2VPN MIB, as I was unable to attend.
In response to the comments listed at the link below which
Shane provided, and start with "TDN:"

3) Virtual Private Lan Services (VPLS) Management Information Base
http://www.ietf.org/internet-drafts/draft-nadeau-l2vpn-vpls-mib-00.txt
Rohit  Medirrata ([email-masked])

Presentation:
    + Scope of the MIB: limited to VPLS as per VPLS-LDP draft. Does not
      have VPLS-BGP, yet.
    + List of Tables:
      - vplsConfigTable contains VPLS-wide parameters. Config table has
        e.g. timeout for how long before you time out a MAC.
      - vplsPwBindTable contains PW configuration. Bind table would be
        e.g. "PW is spoke" or "PW is mesh".
    + MIB Module Architecture:
      - VPLS MIB sits on top of both PW MIB and Bridge MIB.
      - PW MIB sits on top of MPLS-MIB/PSN-MIB.
        * VPLS MIB is a service specific MIB. So need PW MIB and PSN MIB
          too. Question mark on BRIDGE MIB. Not sure if MAC addresses  
will
          be in BRIDGE MIB or in an additional table in the VPLS MIB.
          Looking for WG consensus on that...
     + MIB usage. To configure VPLS service, need 3 tables:
      - vplsConfigTable: indexed by vplsIndex
      - pwTable: indexed by PW index; and,
      - vplsPwBindTable: uses both indexes.
        * PW bind table required because there are multiple PWs per  
VPLS.
          Binds from VPLS config table to PW table (from PW MIB).
    + Future enhancements:
      - Where to store MAC addresses and related information? Bridge MIB
        or VPLS MIB? Constraint on BRIDGE MIB is qualified vs qualified
        learning.
      - VPLS MTU (need a VPLS-wide MTU as well as PW MTU)
      - Not convinced we need to be able to disable MAC learning, or to
        discard unknown destination addresses.

TDN: I agree, and this seems more of a proprietary feature to me.

      - Need some way to configure MAC aging.
      - Need to be able to configure max MACs to learn, number  
learned so
        far, etc.
      - Also, no definition of how to handle multicast frames.  Would be
        nice to have options to config IGMP and/or PIM snooping.

TDN: I want to avoid adding that stuff if we can. I want the L2VPN MIB
	to focus on the basics of L2 VPN.

      - Requirement to modify PWE3 MIB so PW can terminate on a VSI
        rather than on an AC, so need to talk to PWE3 WG about that.
      - No way of provisioning primary/standby PWs.
      - Bind table:
        * Also good if we could configure PW as spoke or mesh.
        * MAC address limit may be per VPLS rather than per PW, so may
          remove that object.
      - Do we merge this with VPWS or IPLS MIBs?

TDN: Specifically which MIB modules are you referring to? For VPWS,
	the PWE3 MIBs already handle this, so there is no reason
	to merge anything.

Discussion:
* Giles Heron - Concerned that we're putting feature specific stuff into
   the doc.  If different vendors do e.g. MAC limiting in different ways
   then is it OK to put it at PW level or at VPLS instance level etc.?
   The protocol drafts don't talk about this so why put it in the MIB?
   Or, should we put this in enterprise MIBs?  I'd like to see what  
others
   think about this.

TDN: We tried to keep the MIB as simple as possible although a few
	things one could consider feature-specific did creep in.

* Vach Kompella - It is hard to draw the line between objects, but it is
   a good thing to have a standard.  If not, make it Informational.

TDN: I totally object to making a MIB module Informational.

* Bruno R. - Some of the data plane objects might be common to VPLS-LDP
   and VPLS-BGP.  Haven't read in detail so don't know if it's really
   specific to LDP.  If so, then could we separate out the common parts
   so they can be re-used for VPLS-BGP in future?
* Rohit - Sure, something to consider.
* Kireeti Kompella - Need per AC as well as per PW stuff.  Have had
   requests, for example, to only allow one IP per AC (to ensure  
there's a
   router there).  Two things going on: 1) VPLS standard that says  
how to
   do VPLS signalling; and, 2) VPLS MIB that has features in that are
   implementation specific.  That's not necessary for interop, yet has
   become part of a proposed standard.  So people say "do you support  
this
   RFC"?  Local implementation things shouldn't become part of proposed
   standard.  So maybe could have normative and non-normative stuff.   
Not
   sure if that can be done in the same document.  Not necessarily an
   enterprise MIB, but at least a separate RFC with different status.
   Really a question for the AD.

TDN:	There is already per-AC configuration/mgmt using the framework
	provided by the PWE3 MIBs. Please look at that and tell us
	if that is insufficient.

* Mark Townsley (as AD) - Don't understand split of doc into normative
   and non-normative.  Came up in another WG today.  Don't think we have
   a process.  So would have to split docs.  If consensus of group is  
that
   implementation specific stuff shouldn't be on standards track then
   should split it up.

TDN: I think there is precedence for doing this already: normative
	stuff based on specific standards documents goes in the
	standards track MIB module, and everything else goes in
	vendor-proprietary MIBs (informative).

* Vach - I would throw everything in there.  If people think all that
   stuff is a good thing to have in a standard, then that's good.  If  
not,
   then we'll take that stuff out and decide whether to make it
   informational.  The problem at that point is you can't put the  
objects
   in the standard table, so you have to put them in another one.

TDN: I would prefer to keep things as simple as possible. This makes
	it more likely to interoperate, as well as pass through the
	jungle of IETF MIB approval process.

* Andrew Dolganow - There is a compliance statement in the MIB which
   could be used and keep both in the same document.

TDN: The compliance statements have largely been used in two
	forms for the past dozen or so standards-based MIBs I have
	been involved in: read-only and read-write.  Doing much more
	than that makes the MIB extremely complex to specify.
	Thus, I would strongly advise against using the conformance
	statements as a means to filter out "everything" as Vach
	said above. Lets keep it as simple as possible, and no
	simpler.

* Mark - I'll do some homework on this.  Don't want to saddle WG with
   splitting docs/MIBs if there's no need.
* Kireeti - If there's consensus that this is important then, let's put
   them in, but not if different vendors do stuff in different ways.
* Mark - seems like we're agreeing, but we need to figure out the
   details.
* Bill Fenner - You can use the compliance statement to manage mandatory
   and optional objects in the same MIB.  If it's on a device that  
can do
   "foo" then this group is required to manage the foo.  All in
   descriptive text, not machine readable.  One big MIB with optional
   sections to manage features you may or may not be able to do is OK.

TDN: It is frankly easier to just use the module construct as a  
filtering
	mechanism for this rather than the compliance statements. The latter
	can be rater cumbersome to construct, especially if you need a read- 
only
	and read-write flavor for each.

* Mark - There's no issue about stuff that is pseudo-vendor specific
   being in a standard doc?
* Bill - It's feature specific, not vendor specific.

TDN: One last question that I meant to pose to the WG that was not  
raised
	as far as the meeting minutes were concerned is whether or not
	to make this MIB read-only or read-write. Given the significant
	effort needed to make the MIB properly read-write, as well as
	the lack of support for read-write MIB objects by vendors (most people
	today seem to use XML or CLI-based configuration) I would like to
	ask the Chairs that there be sufficient consensus from the WG before
	we go down this road.

TDN: Also, should draft-nadeau-l2vpn-vpls-mib-00.txt become an L2 VPN WG
	document?

	--Tom