Subject: RE: questions on INFORM draft

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 21 Aug 2002 12:05:27 -0400

> > If the receiving BGP peer determines that
> > the NLRI is invalid, it should have a way to say something 
> is wrong with the
> > given packet and maybe send it back as an attached data 
> portion to an INFORM
> > message.
> 
> If we have determined that some portion of the packet is bad - say
> the route origin (e.g. type=4), can we trust the rest of the packet?

NO
> 
> If we trust the NLRI is correct and well formed, we could then 
> delete those NLRI as being "bad" from our adj-ribs-in for that peer.
> 
> If we can't trust them, all we can know is we're out of sync with that
> peer.  We may have to mistrust up to a full-packet's worth of
> routes - but which ones?

I suggest, we ignore the packet with bad/malformed data in its PDU/NLRI
section
and send it back as an INFORM message to let the originating peer either
repair the packet and retransmit or drop the session. 
One possible advantage is that it gives the offending peer a second chance 
to repair the problem before a session disconnect is done by either side of
the connection.

In a previous mail someone said if a peer sends a bad/malformed packet it is
suffering from a software error that is not recoverable. I contend that some
software errors are recoverable, especially if in the future we have
multiple
instances of BGP engines within a given router, with backup capabilities. 

Ben

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Aug 2002 09:46:29 -0400

> > the route origin (e.g. type=4), can we trust the rest of the packet?

[...]

> repair the packet and retransmit or drop the session. 

Sending the packet back wont do a lot of good.
I don't think current implementations bother to hold onto the
completed BGP buffer/PDU once it has been transmitted.

If you added a postive acknowledgement mechanism (possibly by overloading/
actually using the marker field), then this might work.

I don't see this happening in the reasonable future.

-- 
Jeff Haas 
NextHop Technologies