Subject: [Idr] multiprotocol extensions to BGP-4

From: Atanu Ghosh <[email-masked]>
Date: Fri, 24 Oct 2003 15:52:16 -0700

I want to know how to process an update packet containing a
Multiprotocol Reachable NLRI or a Multiprotocol Unreachable NLRI for
an AFI/SAFI, when both sides did not send send the appropriate
capability.

Lets consider the four multiprotocol capability exchange options:

1) Capability exchange: Local no | Peer no
The local BGP has not told its peer that it can handle this attribute.
As the attribute is non-transitive it can legally be silently dropped.

2) Capability exchange: Local no | Peer yes
The local BGP has not told its peer that it can handle this attribute.
As the attribute is non-transitive it can legally be silently dropped.

3) Capability exchange: Local yes | Peer no
Both sides did not agree on exchanging multiprotocol attributes. The
local BGP did signal that it was willing to accept multiprotocol
attributes.

	a) Accept the attribute.
	We have signalled that we will accept this attribute, so
	accept it and process it. This is a little weird as the peer
	will never receive a multiprotocol attribute from us.

	b) Silently drop.
	This choice doesn't seem to make much sense.

	c) Send a notify to the peer and drop peering.
	We didn't both agree to exchange multiprotocol attributes and
	now we receive one. Is this an error?

4) Capability exchange: Local yes | Peer yes
The normal case.

For cases 1 and 2 it could be argued that a notify should be
generated?

For case 3 what is the correct behaviour?

In the error handling section in rfc2858, a behaviour is defined for
attribute error. Is receiving a multiprotocol attribute when one was
not expected an error?

Should the error handling section of rfc2858 be expanded to cover the
case of receiving an unexpected well formed multiprotocol attribute?

I had been using draft-ietf-idr-rfc2858bis-03.txt which expires
January 2004. This draft is no longer mentioned on the idr web pages?

	Atanu.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr