Subject: Re: draft-ietf-ppvpn-mpls-vpn-04.txt

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 02 Dec 2002 15:11:35 -0500

>Hi,
>
>Had a few questions on this MIB.

         Thanks for the review. Sorry for the delay in
responding. I started replying an forgot about it
for some reason.

>1) the name of the mib is 'MPLS/BGP Virtual
>Private Network Management Information Base
>using SMIv2' and the abstract says that
>this MIB is based upon draft-ietf-ppvpn-rfc2547bis-02.txt
>which has the title of:
>
>'BGP/MPLS VPNs'
>
>So my question is: could this MIB follow the draft
>that is associated with it and be called
>'BGP/MPLS ...' ?

         Need to make consistent.

>(also section 6.0 refers to BGP/MPLS VPN and not MPLS/BGP VPN)

         Confusion on our part. We will make consistent.

>2) The MplsVpnName which is a 32 Octet string, which
>may or may not be the VPN ID.  Could the description be
>clarified to say if the VPN ID is not used as the value,
>what the value is supposed to be?  (If not in the TC then
>maybe in the index itself).

         Good idea.  Will update to be specific.

>Also, I do not understand how this index could be
>a NULL string for more than one VPN, otherwise, it
>would be difficult to interpret which VPN an interface
>belongs to.
>
>Is this possible?

         No. Just like it is impossible to have two VRFs with the same
name on a PE, it is not possible to have two entries in the MIB
with the same name.   At least that is my understanding based
on my implementation and the others I know of.

>3) The following objects might work better
>as Gauge32:
>
>mplsVpnVrfActiveInterfaces
>mplsVpnVrfAssociatedInterfaces
>mplsVpnVrfPefCurrNumRoutes

         Cool.

>4) There are references to an MPLS-VPN Interface and
>yet the MIB uses mpls(166) or mplsTunnel(150)
>for the ifType.
>
>Was a new  Mpls-VPN ifType considered?   (The reason
>a new ifType might want to be considered is because
>if 2 (or more?) ifTypes are possible
>to uniquely identify a BGP/MPLS interface, a new ifType
>might be cleaner, especially if the MplsVpnName is allowed
>to be NULL.

         We need to remove the references. We did not have
enough time to clarify the text during the last edits.

         --Tom