Subject: a doubt in draft-ietf-mpls-ftn-mib-01

From: Rajneesh Mahajan <[email-masked]>
Date: Mon, 11 Jun 2001 15:23:10 -0400

Hi

The draft-ietf-mpls-ftn-mib-01 on MPLS FTN MIB specifies a lower and an
upper end of the destination address range for a FEC. So it seems to
suggest that there could be only one address range for a FEC. But there
could be a situation when multiple address ranges (e.g. multiple dest
address ranges) are used to classify packets into the same FEC.  I am
not sure how we can handle such a situation with current MIB
specification.  I would appreciate any suggestions/clarification in this
regard.

-Rajneesh

---

From: "Cheenu Srinivasan" <[email-masked]>
Date: Mon, 11 Jun 2001 15:35:01 -0400

> suggestions/clarification in this

You would create multiple entries in the table, one per range that
you want to match.

---

From: Rajneesh Mahajan <[email-masked]>
Date: Mon, 11 Jun 2001 16:13:43 -0400

Hi Cheenu

Thanks for your prompt response. I see one possible problem with having
different entries in this case. All the destination address ranges should
map to same FEC, hence logically there should be only one FTN entry for
them.

For example, lets consider the situation when a router wants to give same
treatment to the packets destined to a set of destination networks (which
means different address ranges). So it would like to map them to a single
FEC and hence single FTN. Having different FTN entries for all these
address ranges would cause lot more FTN entries than required and could
lead to several complications (e.g. memory wastage).

Please note that I am using only the destination address for mapping
packets to FECs. I am not using source address, port numbers and protocol.

-Rajneesh

---

From: "Cheenu Srinivasan" <[email-masked]>
Date: Mon, 11 Jun 2001 18:10:17 -0400

> packets to FECs. I am not using source address, port numbers 

You can specify the same action for multiple entries so all these
packets get the same treatment. While the ability to specify arbitrarily
complex patterns inside the packet header in a single entry might be
considered desirable by some folks, practical reasons and WG feedback
guided us into picking the fields you see in the current MIB.