Subject: [Idr] Filing down the rough edges of draft-ymbk-bgp-extended-messages-02

From: Jeffrey Haas <[email-masked]>
Date: Sun, 17 Apr 2011 13:57:47 +0000

WG,

This thread is my attempt to try to centralize some of the known rough edges
of this draft with respect to RFC 4271 et al. updates.  If possible, I'd
like to suggest that the issue of the maximum send and receive size remain
in a separate thread since that is still contentious enough to require
separate tracking.

Jakob Heitz brought up the point that our holdtimers can't be measured by
the receipt of the start of the received packet.  While I hate to say it,
this has implications on the RFC 4271 FSM especially with regards to the TCP
state machine. :-/

In particular, the text in section 8 is TCP framing unaware.  This was an
issue in the original text and no one really wanted to make complicated text
any worse.  But the implication is that events that rely on receiving a
given message such as an UPDATE are only supposed to succeed when you've
parsed a valid message.  A slow peer sending down a 4k UPDATE a few byte in
each TCP segment at a time would already cause problem.  Such slow peers
will be a bigger problem spec-wise.

(It's my personal opinion that it starts becoming a matter of local choice
how this issue is dealt with.  You can either choose to be pedantic about
the spec and risk sessions bouncing on aggressive timers when you have a
sluggish peer or you can risk keeping alive a bad session when you slip your
timers based on any I/O.)

Constraints on variable sized lists:

Like it or not, the 4k message size provided a nice upper bound to certain
types of foolishness.  As one example, the AS_PATH could never be longer
than what could be maximimally packed into a 4k UPDATE with a single prefix,
message overhead and minimal path attributes needed for iBGP.  It's my
belief that many implementations have an upper bound on this length as well.

Such constraints also applied to things like communities and extended
communities.  It's my belief that for regular communities, current
operational practices tend to constrain the number of communities attached
to a route within a service provider.  But as already mentioned, for
extended communities - particularly route targets - this has been a scaling
issue for certain types of deployments.

While outside of 4271, Route Reflection Cluster Lists are also variably
sized.  Route selection and loop detection will generally provide an upper
bound on this value.

It should be considered whether we want to place any types of upper bounds
on such lists and whether such limits should be required for new drafts that
contain variable sized lists.

Formal changes for RFC 4271 (tedious bookkeeping):

Note section 6.1 and that the value should be 65535 when the capability is
negotiated.

Error handling:

Depending on the resolution of the thread on maximum send/receive message
sizes, we may need a slightly more precise NOTIFICATION code for lengths
than "Bad message length".  This will somewhat depend on whether the
semantics of the extended message draft require a MUST support 65k messages
when negotiated or not.  The draft is currently silent on this (yes, a nit).

-- Jeff