Subject: RE: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01

From: "Lai, Wai S (Waisum), ALABS" <[email-masked]>
Date: Fri, 20 Feb 2004 07:03:22 -0600

Further comments on the -02 version.
As discussed in attachment 1, a new counter is proposed to
provide a rough estimate of the number of dropped routes when
the operator-defined VRF maximum route threshold is exceeded.
The practical use of such a dropped-route counter is presented
in attachment 2.
It does not appear that this counter is included in the -02
version.  Please clarify.
Thanks, Wai Sum

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, February 19, 2004 9:28 AM
To: 'Ross Callon'; [email-masked]
Subject: RE: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ross Callon
> Sent: Wednesday, February 18, 2004 12:55 PM
> To: [email-masked]
> Subject: Re: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01
> 
> 
> With my "individual participant" hat on, I have a few comments, 
> mostly editorial, on this draft.
> 
> - First of all, the -02 version has been published, and thus I will
> comment based on draft-ietf-l3vpn-mpls-vpn-mib-02.txt.
> 
> - The title has a dangling "Using" in it. Also, it seems that the
> term "BGP/MPLS" is used more commonly than "MPLS/BGP".
> Thus I believe that the title should be changed to:
> 
>          BGP/MPLS Layer 3 Virtual Private Network Management 
> Information Base

	Yup, typo.

> - Second paragraph of the status section: Change "In ternet" 
> to "Internet". 

	OK.

> - My understanding is that this document is the MIB for "BGP/MPLS 
> IP VPNs" as specified in <draft-ietf-l3vpn-rfc2547bis-01.txt>. 

	Yes.

> The abstract
> seems to be not quite as precise as it could be in stating 
> this. How about changing the abstract to be: 
> 
>          Abstract 
> 
>          This memo defines an portion of the Management 
> Information Base (MIB) 
>          for use with network management protocols in the 
> Internet community. In 
>          particular, it describes managed objects to 
> configure and/or monitor 
>          BGP/MPLS IP Layer 3 Virtual Private Networks 
> [reference] on a Multi-
>          Protocol Label Switching (MPLS) enabled Label 
> Switching Router (LSR) supporting this feature.

	OK.

> This same change will also effect the first paragraph of section 2.0 
> (Introduction). 

	OK.

> - In a similar vein, there are many places where the document 
> refers to "MPLS L3 VPNs". I would be inclined to change this to 
> "BGP/MPLS L3 VPNs". 

	Hmm, I just went through and changed everything 
from "BGP/MPLS L3 VPNs" to "MPSL L3 VPNs" because I thought it
was clearer. :(  

> I think that this is a bit more precise, and might
> avoid confusion with any other sort of L3 VPN which makes use of MPLS
> (eg, in principle one could use MPLS LSPs between VRs, which is not 
> in the scope of this MIB as I understand it). 

	OK.	

> - The reference also needs to be updated in a couple of ways. 
> On the one 
> hand, the reference to the "BGP/MPLS IP VPNs" document is 
> quite out of 
> date (it should be to draft-ietf-l3vpn-rfc2547bis-01.txt). 

	OK.

> Also, I would expect 
> that at some point the "BGP/MPLS IP VPNs" document will probably be 
> published as an RFC, and that people will stop referring to 
> the approach as "2547" since there will be a different RFC number for
the 
> approach. Thus I 
> would think that a reference with a pointer such as [BGP/MPLS VPNs] 
> would be better than [RFC2547bis]. Actually, elsewhere in the document
> the reference is listed as [MPLSBGPVPN], while in the 
> reference section it is listed as [RFC2547bis].

	OK.

> - I found the second paragraph of the terminology section 
> confusing. It currently states:
> 
>          Throughout this document, the use of the terms 
> "Provider Edge (PE) and Customer Edge (CE) or PE/CE" will be replaced
by 
> PE in all cases except when a network device is a CE when used in the 
> carrier of carriers model.
> 
> To me this seems to imply that where you want to say "Provider Edge"
> you will say PE, and where you want to say "Provider Edge or Customer
> Edge" you will say "PE". Is this right? It seems to me that 
> (i) The terms
> "PE" and "CE" are very standard VPN terms; and (ii) If you want to say
> "provider edge or customer edge" you should say "PE or CE". Thus, I
> would be inclined to delete this paragraph. 

	Done. Less is more! *)

> Also, I think that it would be
> useful to add a reference to the terminology draft to the 
> first paragraph of the terminology section (see 
> <draft-andersson-ppvpn-terminology-04.txt>).

	Good point. I hadn't thought of that.

> - Section 5, last bullet item, this currently states:
> 
>          - LDP paths or traffic engineered tunnels should be 
> configured between PEs and CEs. 
> 
> With layer 3 VPNs (whether based on BGP/MPLS VPNs or on VRs)
> the LSPs are not normally set up to the CE devices. 

	True, we should state something like:

	LDP paths or traffic engineered tunnels should be 
established between PEs, and in some cases (Carrier's 
carrier/inter-AS), possibly betweeen PEs and CEs.

> Also, the LSPs
> don't need to be manually configured, they could be set up via 
> signaling. 

	We were trying to state that the LSPs (however setup) are 
an a priori assumption.  Does the above look ok?

> Also, this sentence seems to assume that if the LSPs are
> set up using RSVP, then this must be for the purpose of traffic
> engineering. In fact, this sentence seems to be getting to the
> requirement that LSPs are set up between PE devices. So why not
> say so by changing this bullet item to:
> 
>          - LSPs should be set up between PEs. 

	Yup. See above.

> - Section 6.2, mplsL3vpnIfConfTable
> 
> This currently reads: 
> 
>          This table represents the MPLS L3VPN-enabled interfaces 
>          that are associated with a specific VRF as represented in 
>          the aforementioned mplsL3VpnVrfTable. Each entry in this 
>          table corresponds to an entry in the Interfaces MIB... 
> 
> There is a nit here: For the interfaces between any particular PE 
> and any particular CE: In general this interface will be associated
> with a particular VRF. However, in general you won't be actually
> running MPLS over this interface and don't need to be running 
> BGP over this interface. 
> 
> Thus in a sense you aren't actually 
> operating the BGP/MPLS L3 VPN protocols over this interface,
> but are instead running "ordinary" routing stuff over this interface,
> which then gets associated with the appropriate VRF. 
> 
> Thus, perhaps this paragraph should start out as:
> 
>          This table represents the interfaces that are associated 
>          with a specific VRF (and therefore are part of a 
> particular VPN
>          being supported using BGP/MPLS L3 VPNs) as represented in 
>          the aforementioned mplsL3VpnVrfTable. Each entry in this 
>          table corresponds to an entry in the Interfaces MIB...

	I can live with that. 8)

> Another question on the same paragraph: In general a PE device will
> have one or more interfaces to P devices. Any one interface from PE
> to P device may support multiple LSPs to other PEs, and any one
> PE to PE LSP may support multiple VPNs. Thus the interface from 
> PE to P may in some sense be used to support multiple VPNs. Are
> the PE to P interfaces included in the mplsL3VpnIfConfTable? My 
> understanding (which might be wrong) is that they are not. 

	The core-facing interfaces are not included, only the CE 
interfaces (or ASBR ifs in the CsC case). 

> - A very minor nit on page 6, (part of section 8), in the 
> description of 
> MplsL3VpnName. Here you refer to the BGP/MPLS L3 VPN approach
> as "MPLS/BGP VPN". In fact I have seen this written as both 
> "BGP/MPLS VPNs", and "MPLS/BGP VPNs". It seems to me that 
> it is a bit cleaner to pick one way of writing the 
> terminology and stick
> with it, and it seems more common to put the BGP first. I agree that
> this is a pretty silly nit, but it seems that it might be 
> slightly less confusing to be consistent (both within any one document
and 
> between documents). 

	I will go through and make sure things are consistent.

> - I think that the reference to [VPNTCMIB] also should be updated,
> although you should know better than me. 

	Yes, I think we will straighten that out during this 
editing phase. There was some confusion about the naming of
the MIB and so on, which I think is okay now.

	Thanks for the comments.

	--Tom

> thanks, Ross
> 
> At 01:42 PM 1/30/2004 -0500, Ronald Bonica wrote:
> 
> >Folks,
> >
> >This message initiates a WG last call on 
> draft-ietf-l3vpn-mpls-vpn-mib-01.
> >The last call will end on February 13.
> >
> >                                                           Ron
> >
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of
> >[email-masked]
> >Sent: Friday, January 30, 2004 11:50 AM
> >To: IETF-Announce:
> >Cc: [email-masked]
> >Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-01.txt
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >This draft is a work item of the Layer 3 Virtual Private 
> Networks Working
> >Group of the IETF.
> >
> >         Title           : MPLS/BGP Layer 3 Virtual Private 
> Network Management Information
> >Base Using
> >         Author(s)       : T. Nadeau
> >         Filename        : draft-ietf-l3vpn-mpls-vpn-mib-01.txt
> >         Pages           : 35
> >         Date            : 2004-1-29
> 
> 
> 

Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt
From: "Lai, Wai S (Waisum), ALABS" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, "Loa Andersson" <[email-masked]>, "Ron Bonica" <[email-masked]>, <[email-masked]>, "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Chung, Li-Jin W, ALABS" <[email-masked]>
Date: Wed, 20 Aug 2003 06:00:00 -0600

At the initiation of Ross Callon, a meeting was held during the
IETF'57 in Vienna to discuss the VPN-MIB requirements described
in the following draft
http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt 
Participants were Ross Callon, Ron Bonica, Loa Andersson, Tom
Nadeau, Jerry Ash, Li-Jin Chung, and Wai Sum Lai.

As a result, it was agreed that a new counter is to be added to the
VPN-MIB to provide a rough estimate of the number of dropped routes
when the operator-defined VRF maximum route threshold is exceeded.
(see Section 3.1 of the draft).  Such count is needed for capacity
planning and threshold tuning purposes.

It was also agreed that the RT/RD linkage in VPN-MIB (Section 3.2)
is to be handled by the NMS.

Comments on this are welcome.
Thanks, Wai Sum

-----Original Message-----
From: Lai, Wai S (Waisum), ALABS 
Sent: Thursday, May 01, 2003 9:02 AM
To: [email-masked]
Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt

Based on our testing of the VPN MIB, we have identified some
requirements
as described in the following draft.  Your comments are welcome.
Thanks, Wai Sum

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 01, 2003 7:48 AM
Cc: [email-masked]; [email-masked]
Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Network Management Requirements for MPLS MIBs
	Author(s)	: W. Lai, L. Chung
	Filename	: draft-lai-mpls-mib-rqmts-00.txt
	Pages		: 6
	Date		: 2003-4-30
	
In this document, requirements for three MPLS-related MIBs (LDP-MIB, 
VPN-MIB, and BGP4-MIB) are presented for the support of specific 
network management needs for fault and performance management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt

Subject: RE: Proposal for MPLS-VPN-MIB enhancements
From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: <[email-masked]>, "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, "Chung, Li-Jin W, ALABS" <[email-masked]>, "Van der Linde, Harmen, ALABS" <[email-masked]>, "Zhang, Leah, ALABS" <[email-masked]>
Date: Wed, 13 Nov 2002 17:51:30 -0600

Tom,

   Regarding (1) about the practical use of the dropped-route count,
here are some examples:
1. Engineering of the routing table - to properly tune its size via
   the max threshold.
2. Understanding of customer demand for prefix routes - increase in
   demand could be due to growth of the business, or re-homing.
   Re-engineering effort might be needed if this is the case.
3. Trouble shooting and understanding the customer service impact -
   customer might inject too many routes due to provisioning errors. 
4. Router resource management to optimize router performance - the
   overflow counts can be summerized at the per router level for
   forcasting and capacity planning.

   Regarding (2) about VRF/RD/RT association, the proposal is to
associate RT with the RD index and not the VRF name index.
Currently, the mplsVpnVrfRouteTargetTable table is key on the VRF
name, but one VRF name could have two or more RD number assigned to it.
Also, while the mplsVpnRouteTarget uses the same format as the
mplsVpnRouteDistinguisher, it does not provide the RD index.
An explicit association between RT and RD is needed.

   In this connection, I believe that some clarification of the
example in "Defining the VPN," page 8, is needed.  Clearly, the
first "100:1" in mplsVpnVrfTable is the RD number.  However, the
second "100:1" in mplsVpnVrfRouteTargetTable should be the RT number
and not RD number, am I correct?  If this is the case, then giving
the same number to RD and RT may cause ambiguity in the example.

Thanks, Wai Sum.

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, August 21, 2002 1:36 PM
To: Lai, Wai S (Waisum), ALASO
Cc: [email-masked]
Subject: Re: Proposal for MPLS-VPN-MIB enhancements

>I would like to propose the following enhancements for consideration in
>draft-ietf-ppvpn-mpls-vpn-mib-04:
>
>(1) Currently, there is the mplsNumVrfRouteMaxThreshExceeded
>notification
>when the VRF maximum route threshold is exceeded.  It is suggested to
>add
>a counter for the number of routes dropped due to such threshold being
>exceeded.  The reporting of such a count is useful for capacity
planning
>and for threshold tunning purposes.

         What practical purpose do you see in counting routes that are
not added beyond knowing that you have exceed that operator-defined
threshold?

>(2) In the mplsVpnVrfRouteTargetTable table, it appears that there is
no
>explicit mapping between the route targets (RT) and their associated
>Route Distinguisher (RD).  It is suggested to add such association
between
>VRF, RD, and RT in this table.

         What do you mean by an explicit mapping -- an index? The
current RouteTarget table contains the associated RD for each
RT entry:

MplsVpnVrfRouteTargetEntry ::= SEQUENCE {
      mplsVpnVrfRouteTargetIndex      Unsigned32,
      mplsVpnVrfRouteTargetType       INTEGER,
      mplsVpnVrfRouteTarget           MplsVpnRouteDistinguisher,
      mplsVpnVrfRouteTargetDescr      DisplayString,
      mplsVpnVrfRouteTargetRowStatus  RowStatus
    }

         --Tom

>Comments are welcome.
>Thanks, Wai Sum.

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.