Subject: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02

From: Randy Bush <[email-masked]>
Date: Fri, 15 Apr 2011 09:59:15 +0900

A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been
successfully submitted by Randy Bush and posted to the IETF repository.

Filename:	 draft-ymbk-bgp-extended-messages
Revision:	 02
Title:		 Extended Message support for BGP
Creation_date:	 2011-04-15
WG ID:		 Independent Submission
Number_of_pages: 5

Abstract:
The current BGP specification mandates a maximum BGP message size of
4096 octets.  As BGP is extended to support newer AFI/SAFIs, there is
a need to extend the maximum message size beyond 4096 octets.  This
draft provides an extension for BGP to extend its current message
size for BGP messages from 4096 octets to 65535 octets.

The IETF Secretariat.

---

From: Paul Jakma <[email-masked]>
Date: Fri, 15 Apr 2011 11:11:46 +0100 (BST)

Hi,

I have 2 comments, one specifically about this draft and another one 
that's more general about error-handling for over-size messages (may or 
may not be appropriate for consideration in your draft).

1. If we're going to fix the length, could we do something to ensure that 
for each specific BGP message type that it's length, excluding any 
encapsulation of other BGP message types, Lt is << L the BGP message 
length field, so that we can be reasonably confident that even with 
multiple encapsulations of messages we're not going to overflow L.

E.g. if L is to be 64k-1, then could we also specify that UPDATE messages 
should continue to be restricted to 4k? Or if UPDATE must be at least 64k, 
could we have a negotiated mode change for the message header to allow for 
a larger, e.g. MBZ bit + 31 bit, length field?

Given BGP allows packing in UPDATEs, it really might make things simpler 
to encourage BGP speakers to keep UPDATEs significantly smaller than the 
max size whenever possible at least, in a stronger way than the current 
text.

2. What are we going to do about the overflow cases? What should BGP do if 
a speaker deliberately sends an UPDATE out that is stuffed to be /near/ 
the maximum size, such that a speaker further along will, through normal 
BGP operation (AS_PATH addition, e.g.) cause the UPDATE to overflow the 
message size?

We could have a variable length length field I guess. ;)

regards,

--paulj

On Fri, 15 Apr 2011, Randy Bush wrote:

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

-- 
Paul Jakma  [email-masked]  twitter: @pjakma  PGP: 64A2FF6A
Fortune:
Deprive a mirror of its silver and even the Czar won't see his face.

---

From: Keyur Patel <[email-masked]>
Date: Fri, 15 Apr 2011 14:16:21 -0700

Folks,

Rev 2 of the draft makes the Extended message capability symmetrical. With
that change, authors of this draft document would like to propose the
adoption of this work as IDR WG item.

Regards,
Keyur

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 15 Apr 2011 17:33:59 -0400

I'll support it if you change the maximum to 65279 (0xfeff).

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Keyur Patel
> Sent: Friday, April 15, 2011 2:16 PM
> To: [email-masked]; Randy Bush
> Subject: Re: [Idr] New Version Notification for 
> draft-ymbk-bgp-extended-messages-02
> 
> Folks,
> 
> > A new version of I-D, 
> draft-ymbk-bgp-extended-messages-02.txt has been

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Apr 2011 06:41:52 +0900

> I'll support it if you change the maximum to 65279 (0xfeff).

and change current bgp to 4351

randy

---

From: Ilya Varlashkin <[email-masked]>
Date: Sat, 16 Apr 2011 00:38:13 +0200

I'm fine with new version. Support +1

/iLya

>> size for BGP messages from 4096 octets to 65535 octets.

/iLya

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 15 Apr 2011 21:45:58 -0400

as well, this seems good, pls to make this final and publish :)

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 22:16:49 -0400

> I'll support it if you change the maximum to 65279 (0xfeff).

How about send 65279 (0xfeff), and be capabile of receiving 65535
(0xffff)?

Curtis

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 15 Apr 2011 23:01:18 -0400

No. Then my robustness goes away.

Say message 1 had the wrong length. I don't detect it.
Then message 2 breaks. I send a notification for malformed message,
including message 2. This will confuse the debugging effort,
because the real problem was message 1.

It's a small thing, but then 256 bytes in 65535 is also a small thing.

--
Jakob Heitz.

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, April 15, 2011 7:17 PM
> To: Jakob Heitz
> Cc: Keyur Patel; [email-masked]; Randy Bush
> In message 
> <[email-masked]
.ericsson.se>

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Apr 2011 12:13:38 +0900

> because the real problem was message 1.

what happens if it is ten times around?

people don't seem to get it.  the bgp message is X.  if you need more
for something else, make something else larger.  use X+20k or whatever.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 16 Apr 2011 00:04:32 -0400

Your point is that it's senseless to try to
fit the whole message into the error message.
I get that point.

Now, do you get mine?
Never mind if you agree with it or not, do you get it?

--
Jakob Heitz.

> From: Randy Bush [mailto:[email-masked]] 
> Sent: Friday, April 15, 2011 8:14 PM
> To: Jakob Heitz
> Cc: [email-masked]; Keyur Patel; [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Apr 2011 13:07:07 +0900

> fit the whole message into the error message.

no.  my point is that your error message is not a bgp message.  so you
can make it some other arbitrary [ larger ] size.

randy

---

From: Jeff Wheeler <[email-masked]>
Date: Sat, 16 Apr 2011 00:23:34 -0400

> what happens if it is ten times around?

This is a solved problem.  Obviously a diagnostic notification may not
be sent in response to a corrupt diagnostic notification.

> for something else, make something else larger.  use X+20k or whatever.

Which of these things is more valuable to you, Randy?
1) maximum BGP message size being 19 bytes larger; or
2) receiving a diagnostic message if the neighbor is unable to parse a
malformed message

> can make it some other arbitrary [ larger ] size.

If this were true, the options would be:
1) define a completely new protocol and establish a new session to the
neighbors for diagnostic messaging
2) mux a second protocol into the same TCP session as BGP
3) extend the BGP parser to recognize that a specific message type has
a larger length field than 2-octets

Fortunately, the truth is a choice can easily be made to allow
head-room for diagnostic outer-message headers within the
already-defined 2-octet length field, without employing any of the bad
options above.

I object to your reasoning and the current draft.  There is very clear
value to both of Jakob's outstanding suggestions.  You have failed to
demonstrate how either of them may have any cost at all, aside from
reducing the available BGP message payload by 0.4% at a juncture when
the proposed change is increasing it by more than an order of
magnitude.  If you can't afford to sacrifice a few octets for these
valuable features, you need to ask for much more than 65535 bytes
anyway.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Keyur Patel <[email-masked]>
Date: Fri, 15 Apr 2011 21:55:22 -0700

> because the real problem was message 1.

You cant deterministically figure this out ever for all cases. Depending on
an error case you MAY end up sending 2nd message in notification. Reserving
a byte is useless for such a case.

Regards,
Keyur

---

From: Paul Jakma <[email-masked]>
Date: Sat, 16 Apr 2011 12:09:58 +0100 (BST)

> can make it some other arbitrary [ larger ] size.

Can you elaborate?

Do you mean we'd have to have a new draft to a different message format 
from the standard/extended BGP message format? (That format would have to 
have to either have a 'dummy' BGP message header with a special type, or 
else we'd have to change the BGP message marker to effectively use it as a 
distinguishing type). Then we'd have 2 message formats - BGP messages and 
not-BGP messages?

Or if you mean something else?

regards,
-- 
Paul Jakma	[email-masked]	@pjakma	Key ID: 64A2FF6A
Fortune:
You will be run over by a bus.

---

From: Rob Shakir <[email-masked]>
Date: Sat, 16 Apr 2011 17:09:25 +0100

> WG ID:		 Independent Submission

Hi IDR,

I'd like to add my support for the request for adoption for this draft.

I'm somewhat confused by the arguments as to why we gain any advantage from the maximum message length being <65535. If the length of the message is specified incorrectly, such that the actual message is smaller than the length being specified - I can't see how this is recoverable. For any arbitrary length if the actual length is smaller than the specified one, it seems to me that we will have some overlap into the following message.

Reviewing the two threads, I didn't find a clear technical justification for requests for the maximum size being smaller. I'm not sure whether others agree, but I would appreciate a succinct technical summary of this requirement for those of us that do not directly develop BGP implementations please?

In addition, we seem to have strayed away from the key point here. What we are trying to agree here is that there is a requirement for a message length >4K, as such, this is really what the draft now specifies (the symmetry discussions have been resolved). It's on this basis that I support the WG adoption, as the information relayed to us by the SIDR WG appears to indicate a clear requirement for this message size for (at least) this application.

My opinion is that the following statement:

   Applications generating messages which might be encapsulated within
   BGP messages MUST limit the size of their payload to take into
   account the maximum message size and all encapsulation overheads on
   the path the encapsulated data are expected to traverse.

gives guidance for the other issues discussed (e.g. encapsulation), but this standard does not specify any means by which encapsulation will occur, this is within the realm of other documents. As such, these drafts should ensure that they specify behaviour such that their intention is compatible with a fixed maximum message size in BGP, no matter what this value should be.

Kind regards,
r.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 16 Apr 2011 16:13:41 -0400

I have read this draft and strongly support adoption as a WG item...

W

---

From: Randy Bush <[email-masked]>
Date: Sun, 17 Apr 2011 07:35:49 +0900

> the symmetry discussions have been resolved

well, i am less sure.  the first stickler for proper conformance has
written to me privately.  rfc 3392 section 3 sure looks asymmetric.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 16 Apr 2011 19:34:29 -0400

My hold timer just went off. Oh, I had an error burst in my line and TCP choked to a crawl. By the time it recovered enough to send that 65535 byte message, it was too late.

Could we please modify the hold timer rule to reset the timer not when a message arrives on the socket, but every time anything arrives.

--
Jakob Heitz.

---

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

> Title:		 Extended Message support for BGP

I would like to support adoption of this draft as a WG item.

I believe that we have good consensus that this is something we want to work
on even if some of the details still need to be addressed.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 17 Apr 2011 15:55:44 +0200

+1

R.

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 17 Apr 2011 14:07:39 +0000

> gives guidance for the other issues discussed (e.g. encapsulation), but this standard does not specify any means by which encapsulation will occur, this is within the realm of other documents. As s…

I also am generally concerned by this issue.  My suspicion is that in many
cases a transition mechanism that can't rely on "discard unnecessary state
to fit into 4k" will make theoretical features undeployable.  What are we
going to do, have a tunnel attribute that splits up jumbo-UPDATE into
multiple sequence numbered UPDATEs that have to be reassembled by a given
downstream from who knows how many copies of the UPDATE?  Path selection
will make that rather painful.

While I expect the detail of the draft concerning MUST support sizes when
the capability is negotiated to be dealt with, a consequence of a MAY would
be unknowable downstream path sizes.

I don't expect this to be a real issue for some time.  The two scenarios
that extended message sizes immediately address are both appropriately
scoped to not have this problem:

1. SIDR routes can simply drop the necessary path attributes when speaking to a
non-compliant speaker.  The semantics of this have to be dealt with in the
SIDR drafts anyway.

2. Large VPN membership is mostly scoped to within a given AS or at least a
subset of the AS.  VPN route reflector deployments already allow for
disjoint reflectors to be deployed for scalability purposes.

-- Jeff

---

From: Jeff Wheeler <[email-masked]>
Date: Sun, 17 Apr 2011 13:16:39 -0400

Lengthy response to several posts...

On Sat, Apr 16, 2011 at 1:05 AM, Keyur Patel <[email-masked]> wrote:
> Can you please explain what clear value it brings and how it helps solve
> error cases? And while your at it can you also explain how it can be solved
> in existing case of 4091 bytes?

Keyur, I'm glad to explain this (again), but there's a basic
disconnect here between some list posters who have hands-on experience
implementing BGP and similar message protocols, and those who just
don't have that kind of in-depth background.  So before I go into
detail again, I want to remind you of this simple fact:
1) an existing header validation/parser error detection mechanism
already exists, because maximum message size is 4096
2) that mechanism goes away if the maximum message size is increased
to any value above 0xFEFF or 65279 octets
3) the cost of keeping this mechanism is only 256 octets of maximum message size
4) if any foreseeable functionality of BGP will not be possible
because of a < 1% difference in maximum message size, you guys should
be extending the length field beyond 16 bits, not quibbling over 256
octets

You need to understand the cost/benefit here, which has been
repeatedly ignored by Randy when directly asked, and others have not
responded with an opinion on this either.

I view these questions from the perspective of implementation in
software, troubleshooting, and use by operators; and I understand the
importance of communicating my opinion to those on the list who do not
have this kind of in-depth background.  In fact, the reason I have
subscribed to this list and invested time in posting is to turn my
dissatisfaction with the results of these standards processes into
constructive input for your use.

Now the details:

> In cases where the (malformed) update message lengths are longer than actual
> message such things don't make sense at all because it probably has gone
> over a second message. In cases where trailing bytes of the first message
> are more 0xffs all bets are off! Furthermore, you cant figure out from an

If you re-read my first posts on this topic, you'll learn that I very
specifically laid out the limited benefit of Jakob's proposal, which
is to retain the ability to detect "off-by-one" errors in code, which
are common.  It is true that BGP message payload can contain arbitrary
data which might appear to be a valid message, and other kinds of
software malfunction would be untrapped by the existing header
validation mechanism, whether it is retained or not.

I think this is very well understood by anyone who has actually
implemented a BGP protocol speaker.

> Reserving such bytes are nothing but a hack from a developer's pov.  Let me
> assure you that I have no problems reducing message size if you can
> deterministically convince it can solve anything.

It keeps the existing solution, which is that the first octet of the
message length cannot be 0xFF, the constant value of all 16 octets of
the MARKER.  This is how off-by-one errors are able to be detected
when the trailing octets of a message are 0xFF.  Quite simply, if the
parser mistakenly believes that a message begins within the trailing
octets of the payload of Message One, it will know with certainty that
Message One is in error if the length was "too low" by 1, 2, .. 16, no
matter what the trailing octets of Message One's payload contain.

The parser will also know if the transmitted length value in Message
One was "too high" by 1 or 2 -- this is the guarantee that is lost if
the maximum message length may be > 0xFEFF.  Errors from 3 .. 16 will
still be trapped in either case because there is no BGP message TYPE
0xFF, and indeed that value should never be used for a BGP message
TYPE.

> Jakob feel free to explain how its going to help and how are you handling
> current cases of 4091 bytes deterministically!

This works fine today and has since BGP was originally defined in
RFC1105.  The first octet may not be 0xFF.  If a message is 4091
octets long it will encode 0x0FFB into the message LENGTH field,
preceded by the MARKER which is a sequence of octets that are always
0xFF.

Since you are asking this question, I will point out in no uncertain
terms that you do not have the needed protocol implementation
experience to understand the changes which are proposed.  If you
really don't know how these values are encoded for transmission, or
truly do not understand how a message parser works, I am glad you are
asking questions so you can better understand the issue and develop a
more informed opinion, but I have trouble understanding why you would
argue against Jakob's concern if you lack this background and have not
consulted folks you trust to help shape your opinion.

The opinions against limiting message length to 0xFEFF all seem to
come from folks who, to use an analogy, are specifying that cars
should not have a "check engine light" because they don't understand
how it works.  Frankly, you should do more reading or consult people
you trust who do have an in-depth understanding in this area before
you decide that 256 octets more of message length is worth removing an
already-existing error trap.

> Reviewing the two threads, I didn't find a clear technical justification for requests for the maximum size being smaller. I'm not sure whether others agree, but I would appreciate a succinct techni…

In the simplest terms, it is currently guaranteed that a BGP parser
can detect if the message length of a message was off by as much as
-18 octets or +18 octets.  The proposed change to a maximum message
length > 0xFEFF will create corner cases, and it will only be
guaranteed that the parser can detect if the length of a message is
off by -18 to -3 or +3 to +18 octets.  It will no longer be guaranteed
to detect "off by one" (or off by two) errors.  If you've dealt with
developers much, you probably know that "oops, it was an off-by-one
mistake" is a pretty common explanation for bugs of all kinds.

On Sat, Apr 16, 2011 at 7:53 PM, Keyur Patel <[email-masked]> wrote:
> Remember it has to work as well deterministically. ;) This does NOT make it
> Robust.  Why don't you try and explain how your going to identify cases with
> extcomm corruption I talked about or if trailing bytes are all 0xff.

Again, if you re-read my first replies to Jakob's concern, you will
see that I quite specifically identified the error cases that are
affected by this change.  Obviously if the message length is off by 19
or more octets, there is no way to guarantee the parser will trap such
an error, because the payload of a message is arbitrary.  It could
look exactly like a BGP message header.  However, "tricking" the
parser in such a manner is extremely unlikely, because it requires a
sequence of 16 octets which are all 0xFF, followed by two octets which
it would believe to be the length field, followed by one octet which
is a valid BGP message type.  It is well understood that not every
extreme case of incorrect BGP message length can be trapped.

I believe 256 octets less maximum message length is a very low cost
for retaining the guarantee to detect common errors, off-by-one.

On Sun, Apr 17, 2011 at 5:16 AM, Robert Raszuk <[email-masked]> wrote:
> * Declare that the header validation is "outside the scope of your draft"
> and in spite that your draft makes it harder recommend to address it in a

The problem is that this draft directly affects the header validation
mechanism, if it extends the maximum message length beyond 0xFEFF
octets.  They really shouldn't say "oh, ignore the changes we've made
to the validation mechanism included in BGP in 1989 and preserved in
every iteration of BGP since then," while making a wholesale change to
it.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 17 Apr 2011 19:59:51 +0200

Jeff,

> On Sun, Apr 17, 2011 at 5:16 AM, Robert Raszuk<[email-masked]>  wrote:

When quoted I think it is better to quote entire bullet as opposed to 
out of context single sentence. For that matter the second sentence was 
critical and integral part of the option.

Here it is:

* Declare that the header validation is "outside the scope of your 
draft" and in spite that your draft makes it harder recommend to address 
it in a separate document. However that new document must be completed 
before we last call (it is still fine to accept yr draft as WG doc 
today) this document. Otherwise implementations will have a valid reason 
not to implement draft-ymbk-bgp-extended-messages.

And for completeness here was my first option:

* Shorter the message to make sure current code of parsing header will 
still work in this one single particular case. This will allow to leave 
other pieces of error detection to an _independent_ further study and 
move on.

Cheers
R.

---

From: Keyur Patel <[email-masked]>
Date: Sun, 17 Apr 2011 16:21:52 -0700

Jeff,

On 4/17/11 10:16 AM, "Jeff Wheeler" <[email-masked]> wrote:

> don't have that kind of in-depth background.

I take it you don't know who all are involved on this list. And that's okay!
For the future reference lets just avoid trash talk and stick to the
technical points particularly if you have join this list to provide
constructive feedback!

<snip>

> 0xFF, and indeed that value should never be used for a BGP message

<snip>

It doesn't aid any other cases than mentioned above purely from verification
perspective. Furthermore, some of these cases can be misinterpreted
particularly where your former message is corrupted and if you trying to
find a beginning of next message (false positives).

That's why I find the Jakob's argument weak along with arguments you posted
earlier (not that I don't understand the fix).  Lastly if your off by one
octet you are going to find out parsing of the message.

Regards,
Keyur

---

From: Jeff Wheeler <[email-masked]>
Date: Sun, 17 Apr 2011 20:16:08 -0400

> octet you are going to find out parsing of the message.

I agree with you, the error cases that this change affects are limited
to "previous message length off by 1 or 2."  Do you think this is not
worth defending against, at the known cost of "the fix?"

You see, neither you nor any other list poster has said "I think I
need 0.4% more payload more than I need to guard against off-by-one
errors."  If you oppose "the fix," please make your position on this
clear -- that you understand the cost/benefit, have weighed your
options with due care, and formed an opinion that you really want that
0.4%.

On Sun, Apr 17, 2011 at 7:23 PM, Keyur Patel <[email-masked]> wrote:
>> Have you put any thought into what will happen, if indeed the remote
>> neighbor sends an incorrect message length, and the parser thinks an
>> incoming message will be > 0xFEFF octets long?  I have.  One of two
>> things will happen:
>
> And what makes you think that this cant happen today with the 4k limit when
> the message size listed is 4K while actual message was around 200 bytes? Do
> you think the current message length handles it?

If a message length today is off by 1 or 2, it can be detected as soon
as the next message header is received, regardless of any payload.
The parser won't start at the wrong place when looking for the next
message header, see 0xFF octets in the MARKER field, and thing those
are actually the LENGTH, not trailing octets of the misplaced MARKER.
So we won't actually think the message is huge -- we'll know the
previous message header LENGTH field was incorrect and we'll throw a
specific error right away, not sit around and wait for hold-time to
expire or more octets to come in (and trick us into thinking a *later*
message than the malformed one was in error, too!)

> earlier (not that I don't understand the fix).  Lastly if your off by one

If you "understand the fix," why did you state that you would have
nothing more to discuss on this topic until someone posted "C code"
implementing this fault detection?  I have not written some novel
1-liner, I've only tried to make it (more) obvious that the proposed
protocol change breaks an already existing fault detection measure.

Again, if you "understand the fix," will you go ahead and state that
you believe 0.4% more payload is of greater importance than guarding
against off-by-one bugs?

Alternately, would you explain why some work is jeopardized by
whatever delay is needed to change the draft to replace 65535 octets
with 65279 octets?  I readily admit that I do not understand the
standards process.  If you need to say "secure BGP and long poems in
NOTIFICATIONS will be delayed by one year if we make this change," I
might think, gosh, I really do want secure BGP and delaying it is an
unacceptable cost.  However, my suspicion is that s/65535/65279/ is a
pretty light-weight change that does not alter the scope of the draft,
is getting quite thorough debate right now, and is an easy change to
make.

Finally, if neither of these is the case, is there some outstanding
question on your mind?  Are you simply not interested in making this
change because no one(?) thought of it before Jakob wrote his first
post on this issue?

The obvious purpose of an open standards process is to get from
concept to implementation in the best manner, with input considered to
improve upon concept and specifics, catch gotchas (like this one),
avoid duplication of work, and hear feedback from other
vendors/implementors.  That whole process is useless if people simply
railroad their idea through it.  I have yet to read any post that
offers any remotely-legitimate reason why 0.4% of payload is a big
deal -- yet you wish to essentially "close debate and move on."  That
is railroading, plain and simple, and whether it appears to be polite
or not, I am calling it like I see it.

---

From: Keyur Patel <[email-masked]>
Date: Sun, 17 Apr 2011 17:28:36 -0700

> as the next message header is received, regardless of any payload.

That is NOT the case in my example above. Message length is within 4096
bytes (say 4050 bytes) while the actual message was in few hundreds of
bytes. With aggressive keepalive times or partial writes your going to hit
such cases even with 4096 bytes. That was my point.

-Keyur

---

From: Jeff Wheeler <[email-masked]>
Date: Sun, 17 Apr 2011 20:37:46 -0400

> such cases even with 4096 bytes. That was my point.

Yes, but you fail to understand what induces the parser to be looking
for a wrong-length message.

Yes, the remote neighbor can say "4050 octets coming" and only send
200.  We agree that this is bad and there just isn't anything to be
done about it, except wait for the arrival of 3850 octets and then
fail to parse the next header.

The problem is if the remote neighbor says "199" octets are coming,
and then transmits 200.  What happens?  Currently, the LENGTH of the
next message will be, from the parser's perspective, in the wrong
place -- it will see the most-significant-octet as 0xFF (last octet of
MARKER), immediately detect this failure (because LENGTH is > 4096),
and we will know right away that either the neighbor malfunctioned, or
our parser malfunctioned.

If we allow LENGTH to be > 0xFEFF then the above off-by-one case will
NOT be immediately detected, the last octet of MARKER will mistakenly
be seen as the most-significant-octet of LENGTH, and we will be
waiting for at least 65280 octets of data to arrive from the neighbor.

The issue isn't simply "the remote neighbor could compute or send the
wrong length."  I know it could.  The issue is I don't want common
off-by-one cases to be hard to detect/troubleshoot.

---

From: Glen Kent <[email-masked]>
Date: Mon, 18 Apr 2011 07:06:05 +0530

Jeff,

> and then transmits 200.  What happens?  Currently, the LENGTH of the

Why will this ever happen?

Glen

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 18 Apr 2011 11:17:33 -0400

> Why will this ever happen?

You've never heard vendors explain malfunctions as "oops, it was an
off-by-one bug?"  This happens in real-world, production code.  We
should not make that harder to debug.  The proposed change does
exactly that: makes a common protocol implementation bug harder to
diagnose/debug.

Again, Glen, the cost of keeping the existing fault detection
mechanism is 256 octets of message length, or 0.4% of the proposed
maximum.  Do you think that 256 octets is essential?  Is there anyone
who believes we need 65535 octets instead of 65279 octets?

You can talk this to death without understanding implementation
issues, but the simple fact remains that this fault detection
mechanism has always existed in BGP, and the draft proposes to remove
it to gain an inconsequential amount of payload.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 00:50:01 -0400

> Never mind if you agree with it or not, do you get it?

Yes we get it and to repeat a prior point, if the implementation is
*that* brokend it doesn't belong on the Internet, return it to the
vendor and demand a refund.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 02:22:46 -0400

> it to gain an inconsequential amount of payload.

If you want to solve *that* problem, then don't try to solve it in
extended-messages, start a whole new draft and solve it.

Create a new capability that indicates that PPP style byte stuffing
will take place, replacing all FF with FE FF and all FE with FE FE,
excpet in the marker.  Then you can always identify a correct marker
as FF FF, because that can't occur in the payload.

Then you can ask vendors to implement this and see if the number of
off by one errors go up or go down.

It is from a protocol design standpoint bulletproof.  It adds a little
complexity and the cure may be worse than the existing sympton, but
you'll always be able to identify the symptom when it turns up.

Curtis

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 19 Apr 2011 13:05:46 -0400

> extended-messages, start a whole new draft and solve it.

Curtis, again, BGP has had this protection against confusing the
LENGTH field with the MARKER field since BGP version 1.

This is not something that people are trying to sneak in to an
unrelated draft.  In fact, it's the opposite.  Increasing the LENGTH
upper-bound has header validation implications that are non-obvious.
I'm pretty sure Randy still "doesn't get it" since his every post on
this subject has, as yours does, referred to byte-stuffing.

Do you know how many posts there have been that advocate increasing
the message length to 0xFFFF, acknowledge that the existing fault
detection mechanism for off-by-one/two is being removed, and state
that 0.4% more payload (256 octets) is worth losing that *already
existing, since BGP v1* header check?

There are exactly zero posts advocating this position while
acknowledging that they understand the cost/benefit.

That's the issue here: this isn't that easy to understand, and the
process is being driven by folks who haven't taken the time to read a
little more carefully.

Let me put it this way: Do you think, that if the draft authors knew
they would affect header validation when they were originally writing
this proposal, that they would have said "oh, no big deal," and gone
ahead with 65,535 octets of message length?  Or would they have said,
"well, we can get to 65,279 octets without significant affect on the
protocol or code, let's do that?"  I'm pretty sure they would have
gone with the smaller figure.

What you see now is a bunch of folks going "I don't understand these
implementation issues," or "you're asking for something new," (not
true; the draft breaks something that exists).  Except Randy, who has
not contributed anything useful at all, unless you consider his
"cosmic ray" and "SLIP" posts, which indicate he still does not
understand that we're talking about things that happen as a result of
common implementation bugs, not random bit-flips on the wire, as
productive.  If this is really over his head, so be it; but I think
the true case is Randy is simply stubborn, does not want to do an
s/65535/65279/ on the draft, does not have any good argument to defend
his position (0.4% of payload, remember?), and so is playing stupid,
and dragging some of you guys along for the ride.

Again, any reference to SLIP, cosmic rays, etc. is foolish and outside
the scope of this discussion.  Go back and re-read my earlier posts if
you are still confused on this.  The issue is implementation bugs, and
how this draft will make some of them more difficult to troubleshoot
-- it has nothing at all to do with bit-flips on the wire.  If you're
saying "PPP" or anything remotely similar, the discussion is still
going over your head.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 18:01:11 -0400

Jeff,

Nice rant.  :)  Comments inline.

> this subject has, as yours does, referred to byte-stuffing.

The marker field is of limited value.

I was maintaining the NSFNET BGP code as far back as the version 2
days so yes I am familiar with the marker and I quite sure Randy is
too.  Randy and I have been butting heads for more than 15 years so we
sort of know each other by now.

We all get off by one.  We also get using a signed integer instead of
unsigned, etc.

> acknowledging that they understand the cost/benefit.

So apparently somebody doesn't get it.  Maybe its you.

Off by one may be about as common as using a signed integer or any of
a number of other bugs which would result in off by a lot more than
one.  An FFFF could be anywhere in the data.  That is the point of
byte stuffing to have a rock solid marker.  A length slip will always
be picked up fairly quickly.  It is very difficult for it not to be
picked up on the next packet.  With stuffing it is always picked up
immediately.

But I've already said that the marker field is of limited value, so
I'm not advocating byte stuffing, just suggesting that if you want a
more robust marker, consider writing a draft that proposes to use byte
stuffing to make the marker completely robust.  Otherwise, if there is
a slip, find a *potential* marker, interpret a few other fields, like
the length, and resync based on getting a full valid packet, not just
a valid looking marker.

> process is being driven by folks who haven't taken the time to read a

Is the point you are trying to make that if we don't agree with you we
can't possibly understand?

> gone with the smaller figure.

Yes.  I fully believe that the possibility of FFFF in the length field
is not considered an issue and that the draft authors fully understand
that the marker field is of limited value and accept this.

> and dragging some of you guys along for the ride.

Clearly somebody doesn't understand.  I've understood Randy's sarcasm.
Terse but to the point.  Sometimes its the most funny when the person
Randy is responding to just doesn't get it and can't see the sarcasm.

I ageee that Randy is stubborn.  No one will dispute that.  Not even
Randy.  :)

> saying "PPP" or anything remotely similar, the discussion is still

As long as Grandma's dual homed connectivity woes are still in scope,
I'm OK with dropping any discussion on cosmic rays.

Cheers,

Curtis

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Apr 2011 09:43:56 +0900

> Nice rant.  :)  Comments inline.

you are far too patient, curtis.

> that the marker field is of limited value and accept this.

yep

> I ageee that Randy is stubborn.  No one will dispute that.  Not even

i refuse to dispute it!

randy

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 23:36:02 -0400

> you are far too patient, curtis.

Few people accuse me of that.

> > I ageee that Randy is stubborn.  No one will dispute that.  Not even

I thnik he may eventaully get it.

Curtis

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Apr 2011 12:38:50 +0900

> Few people accuse me of that.

well, i doubt we need an impatience contest :)

i procmailed him a far while ago

> I think he may eventaully get it.

i don't.  he is more interested in being 'right' than in the actual
engineering.

randy