[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:





Olav.Kvittem@uninett.no wrote:
[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hello,

http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-02.txt:
  
4.3 Router State filtering 
      This class of filters select a packet on the basis of the
following 
  conditions), possibly combined with the AND, OR or NOT operators. 
       - Ingress interface at which packet arrives equals a specified 
        value 
     - Egress interface to which packet is routed to equals a 
        specified value 
     - Packet violated acl on the router 
     - Failed rpf  
     - Failed rsvp  
    

you mean exceeding reservation contract or failing to reserve ?
Olav, 
this list comes from two mails exchanged quite a while ago on the ML, originated by 
Peram Marimuthu and Rae McLellan, respectively. If they're still on the list they may want to clarify... 

********** Fom Peram's mail 19/08/2002 ***********
You can also select packets based on packet properties - Peer AS, Source
AS, packet length etc or as a result of some processing decisions within a
router (failed rpf, no route etc). Are these within the scope of this wg?
***************************************

********* From Rae's mail 09/09/2002 *************
2) selectors that pertain to a router's reaction to a particular packet.
   - egress/ingress interface this packet is routed to/from == <value> 
   - acl violations
   - failed rpf
   - failed RSVP
   - no route
**************************************************
perhaps this could be generalized to exceeding any Qos-contract like diffserv,
which is probably worth differentiating from dropped due to congestion ?

   - failed conditioning - red
   - dropped from que

I guess the qos area could be tempting to detail even more ?
Could you come with a suggestion that is totally "implementation independent"? otherwise, it may be out of the scope of a standard....
Maurizio

Olav




--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>