Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt

From: [email-masked]
Date: Wed, 22 Aug 2001 07:01:33 -0400

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		: Multiprotocol Label Switching (MPLS) FEC-To-NHLFE 
                          (FTN) Management Information Base
	Author(s)	: T. Nadeau, C. Srinivasan, A. Viswanathan
	Filename	: draft-ietf-mpls-ftn-mib-03.txt
	Pages		: 25
	Date		: 21-Aug-01
	
This memo defines an experimental portion of the Management
Information Base  (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for defining FEC-to-NHLFE mapping and corresponding actions for use
with Multiprotocol Label Switching (MPLS).

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

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-ftn-mib-03.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ftn-mib-03.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.

---

From: "Cheenu Srinivasan" <[email-masked]>
Date: Wed, 22 Aug 2001 13:07:28 -0400

Folks,

Version 03 of the FTN MIB I-D is now available on the IETF
website (see below). We (the authors) believe its ready
for last call at this point. Please email your comments
to the list. Thanks.

Cheenu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 7:02 AM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
> 
>

---

From: Igor Lasic <[email-masked]>
Date: Wed, 22 Aug 2001 17:57:34 -0400

I have some fundamental question/issues with the MIB as it is
  defined today.  

  In networking Access Lists are a general and well understood
  concept. Access lists give one ability to collect matching information
  and then "bind" it to a entity.

  For example:

  acl 1
      10 ip dest address 1.1.0.0 255.255.0.0
      20 ip src address 2.1.0.0 255.255.0.0
      30 allow all

  Where 10, 20 and 30 are priorities for matching criteria. 

  Then one just binds 1 (the acl index) to entity (in this case it could
  be an outsegment entry.) Using the mplsFTNMapTable (I don't think prev
  and curr would be neccessary.)

  Secondly, in the mplsFTNEntry ranges used for matching ip addresses
  are very uncommon way of matching ip routes. In general people use ip
  address/prefix concept.

  I had to make this comments just for my own sake.

  Thanks,

  Igor

---

From: "Cheenu Srinivasan" <[email-masked]>
Date: Wed, 22 Aug 2001 18:21:56 -0400

>   and curr would be neccessary.)

We introduced the linked-list structure in this MIB specifically
to overcome a problem with what you describe - everytime an
entry needs to be inserted into an existing list the ids/"priorities"
of existing items may need to be changed. Either that or one
has to think ahead and leave big enough "holes" in the ids to
allow insertion at a later point (which over time still does not
avoid the above issue).

Implementation wise, one could
continue to internally assign IDs/priorities/whatever and renumber
behind the scenes and save the administrator this pain.

>   are very uncommon way of matching ip routes. In general 

Ranges are a superset of prefixes; implementors who choose 
to restrict their implementation to prefixes only can still do so
by restricting the type of ranges thay accept.

Cheenu

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 22 Aug 2001 22:08:03 -0700

>   and curr would be neccessary.)

         I don't really understand what your question is here. Are you
asking whether or not it is possible/not possible to bind ACLs
to a particular FTN entry, or are you asking weather or not
it is possible to order FTN entries? In either case, it is possible to
do this with the MIB as it is currently written.

>   are very uncommon way of matching ip routes. In general people use ip

         The MIB allows matching of ip address prefixes, or ranges
of prefixes, or other attributes such as port number or TOS bits.
It is general enough to allow the matching of any (or all) of these
things in any order (of preference) that you would like.

         --Tom