Subject: RE: issue 10

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 25 Sep 2002 15:10:32 -0400

Jeff:

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2002 2:54 PM
> To: Yakov Rekhter
> Cc: [email-masked]
> Subject: Re: issue 10
> 
> 
> Yakov,
> 
> On Wed, Sep 25, 2002 at 11:46:45AM -0700, Yakov Rekhter wrote:
> > The real issue here is how to handle the case when a route
> > (a single address prefix + path attributes) doesn't fit into
> > 4K bytes (as the max BGP message size is 4 K). To address
> > this issue I would suggest to add the following to 9.2:
> 
> If I might suggest that although this is the most "valid" 
> (for some value judgement of "valid") case for this problem,
> implementations may choose for whatever reason to deal with
> attribute overflows differently.  For example, if a certain vendor
> didn't want to support AS_PATHS over 256 AS's, that's their
> prerogative.
> 
AS_PATH attribute is a well known mandatory attribute. All vendors that
support the standard RFC1771 BGP protocol must have this attribute in the
payload of the UPDATE message. Your point is not valid.

> Thus, we might want to just say something about "If you can't
> send an update that properly contains all required information,
> do not send the update".  I apologize for not having the proper
> wording for it, but this also covers the case where a packet
> is almost full and you can discard communities (for example)
> to make AS_PATH fit.
> 
My suggestion, is if one prefix with all its mandatory attributes cannot be
sent in a 4K block message. Our network has expanded beyond its original
conception and we need a fast extention to the BGP protocol. 

On the other hand, if we have some abnormal network configuration that cause
this problem or the UPDATE packet is malformed than the proper error 
processing should be done as I mentioned earlier.

Ben
> > Yakov.
> -- 
> Jeff Haas 
> NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 25 Sep 2002 15:21:31 -0400

Ben,

> payload of the UPDATE message. Your point is not valid.

I may be discussing the wrong issue in context of this particular
thread.  Let me tackle the one I was trying to bring up first.

Lets say an implementation can't support an AS_PATH with more than
256 AS's.  Since it can't support it, it MUST NOT propagate that
route if it cannot add on the 257th AS to the AS_PATH.

This is a case where some mandatory behavior causes an overflow
situation - in this case it happens to be an implementation overflow
rather than getting to the point where we're going to overflow the 
BGP PDU.

> My suggestion, is if one prefix with all its mandatory attributes cannot be

note mandatory.
[intentionally skipping the rest since its out of scope for what I
was trying to bring up]

If we're at a point where we need to modify a BGP PDU to do some
sort of mandatory behavior (add an AS to the PATH, append to a
cluster-list, etc.) and we are at an overflow situation, we may
have two options:

1. Is there something that isn't mandatory that we *might* be able to
   discard?  If so, thats a value judgement.  Encoding that value
   judgement in an implementation may be tricky and possibly not
   worth doing.
2. If we can't append, we should not propagate the PDU.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 26 Sep 2002 06:06:16 -0700

Jeff,

> route if it cannot add on the 257th AS to the AS_PATH.

Lets say an implementation can't support BGP_COMMUNITY with more
than 2 communities. Or lets say an implementation can't support
path attributes with more than 255 octets (the implementation
can't support extended length). All these are examples of a
deficient implementation. Specifying operations of a deficient
implementation is certainly outside the scope of the spec.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 26 Sep 2002 11:05:54 -0400

> implementation is certainly outside the scope of the spec.

I would agree.  But specifying general overflow behavior is *not*
out of scope.

In any case, I don't object to leaving this behavior implementation
specific, so I wont argue the point too strongly.

Its probably sufficient to say "If you can't do the mandatory things
you need to do while propagating a route, don't propagate the route".

-- 
Jeff Haas 
NextHop Technologies