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

From: Ross Callon <[email-masked]>
Date: Wed, 18 Feb 2004 12:55:09 -0500

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

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

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

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

- 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". 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). 

- 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). 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].

- 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. 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>).

- 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. Also, the LSPs
don't need to be manually configured, they could be set up via 
signaling. 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. 

- 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...

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. 

- 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 think that the reference to [VPNTCMIB] also should be updated,
although you should know better than me. 

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 19 Feb 2004 09:28:25 -0500

> 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
> 
> 

	Yup, typo.

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

	OK.

> 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 
> 
>          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 

	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

	OK.	

> date (it should be to draft-ietf-l3vpn-rfc2547bis-01.txt). 

	OK.

> Also, I would expect 
> 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 
> 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 
> 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.

>          - LDP paths or traffic engineered tunnels should be 
> configured between PEs and CEs. 
> 
> 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
> 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

	Yup. See above.

> BGP over this interface. 
> Thus in a sense you aren't actually 

	I can live with that. 8)

> 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). 

> 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.

> 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

---

From: Ross Callon <[email-masked]>
Date: Thu, 26 Feb 2004 14:27:25 -0500

This ends the working group last call on draft-ietf-l3vpn-mpls-vpn-mib-01.

Thanks, Ross