Subject: FW: some queries on mpls-ftn-mib-03

From: "Sharma, Prem" <[email-masked]>
Date: Tue, 28 Aug 2001 15:26:38 -0700

Re-sending the mail I sent few days back. Authors, pls. respond.

Prem

>  -----Original Message-----
> From: 	Sharma, Prem  
> Sent:	Thursday, August 23, 2001 1:11 PM
> To:	[email-masked]'
> Subject:	some queries on mpls-ftn-mib-03
> 
> Hi,
> 
> I was trying to see if some consensus has been reached on the following
> outstanding issues w.r.t. mpls-ftn-mib:
> *	Keeping mapping of DSCP values to LSPs/Tunnels 
> *	Use of CIDR prefixes instead of Address ranges.
> *	Keeping IPv6 flow label also. 
> 
> Aforementioned pertain to the mplsFTNEntry in the MIB.
> One more comment: I'll be better if the relation of this draft with
> diffserv mib could be clarified too.
> 
> Thanks.
> Prem

---

From: Igor Lasic <[email-masked]>
Date: Tue, 28 Aug 2001 19:33:54 -0400

> > *	Use of CIDR prefixes instead of Address ranges. 

  Authors seem to feel stronly that ranges are the way to go. In
  practice (from implementation point of view) if one would like to use
  FTN table to insert entries into a forwarding table that does not
  work. Also I question whether people are more used to using ranges vs
  prefix/len (or mask) concept.
  
  My opinion is that FTN table is usable if MPLS has a matching database
  that is outside of IP forwarding and is "sits" logically before IP
  lookup. I am not sure how many people are doing it that way. In our
  case we are not doing it that way (completely.)

  Another FTN feature I question is mapping table. In general when
  filtering is used (which the FTN database implies) people use access
  list concept where matching criteria is organized into lists and lists
  and matching criteria are prioritized. Then there is a mapping between
  the interface and the list not the individual matching criteria.

 I understand that it is possible to reorganize the database better by
  using the FTN implementation but it is not the common industry way of
  doing matching database.

  Please do not take this as an attack, I am trying to be constructive
  and align the FTN mib more with what are common practices in the
  field. After considering FTN mib we have decided not to use it because
  of the above two issues (ranges vs prefix/len and matching criteria vs
  access list.) 

  I promise this is the last time I bring this up. If MPLS community
  does not feel these are valid points that is fine. 

  My $0.02,

  Igor

  Disclaimer: oppinions are my own, I do not speak for the company.

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 29 Aug 2001 11:10:25 -0700

Did you not get our responses?

> > *     Keeping mapping of DSCP values to LSPs/Tunnels

         This exists in the current version.

> > *     Use of CIDR prefixes instead of Address ranges.

         This is supported by the existing MIB in that
you can use address prefix ranges.

> > *     Keeping IPv6 flow label also.

         There were no requests other than yours to add
this, so there was no consensus to add it.

> > diffserv mib could be clarified too.

         Yes, we agreed to clarify the text in the MIB for this.
I also believe that text in the MIB exists which notes that
other packet marking/queuing can take place before the
FTN MIB is inserted into the processing chain.

         --Tom