The MPLS WG Archive

[Cheenu Srinivasan <csrinivasan@tachion.com>]

Title: RE: draft-nadeau-mpls-packet-classifier-mib-01

Adrian,

Thanks for your comments. See responses below.

Cheenu

Adrian Farrel wrote:
> I like this MIB.  Nice and simple!

Thanks! We tried to get rid of a lot of clutter that was there
in the first version including simplifying some of the indexing.

>
> Questions
> =========
>
> mplsPacketClassifierApplied
>   I'd be happier if this was a count.  Easier to work out when to
>   it False.  Probably more useful too.

Good idea. Will do.

>
> Do people do classification based on prefixes, or is max and min
> IP range good enough for this?

Max and min range specification is a superset of prefixes. (For example
192.168.0.0/16 is the same as [192.168.0.0-192.168.255.255].) A specific
implementation can choose to restrict their range support to those ranges
that are expressible as prefixes.

> Editorial
> =========
>
> 4. Motivation
>   I think it would be helpful to exapnd upon "redirect packets
>   into LSPs or TE tunnels" in view of the considerable discussion
>   on the list about when you are allowed to inject packets onto
>   an LSP and when not.
>   What you are doing here is defining precisely the answer to
>   that question.
>
> mplsPacketClassifierProtocol  Description
>   I think this is a little terse.
>  

Will elaborate on these.

> RowPointer
>   Do we need a definition of this textual convention, or can it
>   be imported from somewhere?

RowPointer is a TC already defined in SNMPv2-TC.

> mplsPacketClassifierMapEntry and mplsPacketClassifierMapIfIndex
>   Picky perhaps, but could you insert clarification that the
>   interfaces to which you refer are ingress interfaces.

OK.

>
> mplsPacketClassifierMapTable
>   I think the indexing may need some more thought.  A linked list
>   is certainly useful, but what does it do to the sequence of
>   rows when you walk the MIB?

With the current indexing one needs just a little thought to
retrieve the classifiers in the order of application on a given
interface. For example if the following classifiers are applied
currently on interface 1: 2, 1, 4 to retrieve classifiers in
application order one would issue this sequence of getnexts:

getnext(1, 0, 0) - (1, 0, 2)
getnext(1, 2, 0) - (1, 2, 1)
getnext(1, 1, 0) - (1, 1, 4)
...

where each row above represents:
getnext(ifIndex, prev classifier, curr classifier) - returned entry indexes

We do not need more messages and at the same time have the advantage of
being able to insert/remove classifiers in arbitrary positions. I think
it would help a lot to specify this algorithm in the draft and we will
do this in the next revision.

>
> Typos
> =====
>
> 1. para 1 line 4
>   superfluous "s"
>
> 5. last line
>   insert "classifier" at the start of the line
>
> MplsPacketClassifierEntry
>   formatting
>
> mplsPacketClassifierMask  Description.  4th line
>   missing "classifier"
>

Will fix all these.