The MPLS WG Archive

[Joan Cucchiara x302 <jcucchiara@Artel.com>]

Hi Folks,

The difference between this Version 11 and the prior draft
is that STD is used.  This should compile cleanly with the
latest MPLS-TC-STD-MIB (draft-ietf-mpls-tc-mib-07.txt).

Also, this version has also been updated with MOST of the
comments from the last AD MIB review (see email posted to the
MPLS WG on Friday, May 9th from Bert Wijnen, entitled 
"AD review of draft-ietf-mpls-ldp-mib-10.txt".)

The exception is that comment #3  and the NIT regarding 
mplsLdpPeerTransportAddrType and mplsLdpPeerTransportAddr
have not been addressed in Version 11.  We would like to 
incorporate these as part of this last call.
For your convenience, these are quoted here from that email:

   "3 I see:
         mplsFecAddrPrefixLength    InetAddressPrefixLength,
         mplsFecAddrFamily          InetAddressType,
         mplsFecAddr                InetAddress,
   I believe that RFC3291 suggests to put InetAddressType BEFORE
   any objects that are to be intepreted within the context of
   the specific addressType. so the sequence should probaly be:
         mplsFecAddrFamily          InetAddressType,
         mplsFecAddrPrefixLength    InetAddressPrefixLength,
         mplsFecAddr                InetAddress,

  I would also check the DESCRIPTION clauses with RFC3291.
  I am not so sure it is all in sync with prescriptions of RFC3291
  I am specifically worried about the reference to RFC1700 (which is
  obsolete anyway, probably you better refer to
      http://www.iana.org/assignments/address-family-numbers
  if that is what you want). But is it not just IPv4 and IPv6
  addresses that you support (at least that is what compliance
  seems to state?
  In the DESCRIPTION of PrefixLength I would change 
            "If the value of the 'mplsFecType' is 'hostAddress(2)'
            then this object is undefined.
  Into either:
            "If the value of the 'mplsFecType' is 'hostAddress(2)'
            then the value of object is irrelevant and ignored.
  Or (maybe better, not sure):
            "If the value of the 'mplsFecType' is 'hostAddress(2)'
            then the value should be equal to the length of the
            address in mplsFecAddr.
  Also in that same DESCRIPTION clause:
             prefix matches all addresses.  In this case the
             prefix MUST  also be zero (i.e. 'mplsFecAddr' will
             have the value of zero.)"
  What is a "value of zero"? I think you mean zero length.
  But in order for that to be valid for mplsFecAddr, the
  mplsFecAddrFamily value should be zero (i.e. unknown).

...  AND

   "I think that the DESCRIPTION for InetAddress object MUST contain
   the explanation how it is interpreted. The example in RFC3291 is
   so explicit and clear (or so I think). I also think that it is
   in fact an Internet address and not a transport address (the
   latter needs a port number too, does it not? see RFC3419)

   <...>
   If you do change this, pls check all your InetAddress objects"

So, we will address these 2 issues as part of this last call.

   Thanks, 
     -Joan

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiprotocol Label Switching Working
> Group of the IETF.
> 
>    	Title   	   	: Definitions of Managed 
> Objects for the Multiprotocol 
>                           Label Switching, Label Distribution Protocol
> (LDP)
>    	Author(s)   	: J. Cucchiara, H. Sjostrand, J. Luciani
>    	Filename   	: draft-ietf-mpls-ldp-mib-11.txt
>    	Pages   	   	: 132
>    	Date   	   	: 2003-6-10
>    	
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in the Internet community.
> In particular, it describes managed objects for the Multiprotocol
> Label Switching, Label Distribution Protocol (LDP).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-11.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>    	"get draft-ietf-mpls-ldp-mib-11.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>    	mailserv@ietf.org.
> In the body type:
>    	"FILE /internet-drafts/draft-ietf-mpls-ldp-mib-11.txt".
>    	
> NOTE:   	The mail server at ietf.org can return the document in
>    	MIME-encoded form by using the "mpack" utility.  To use this
>    	feature, insert the command "ENCODING mime" before the "FILE"
>    	command.  To decode the response(s), you will need "munpack" or
>    	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
>    	exhibit different behavior, especially when dealing with
>    	"multipart" MIME messages (i.e. documents which have been split
>    	up into multiple messages), so check your local documentation on
>    	how to manipulate these messages.
>    	   	
>    	   	
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>