Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 11:30:29 -0400

Yakov:
  That may be true, but I have seen in a couple of BGP implementations
handling the socket level that the BGP code had to reassemble the logical
packet. TCP did not do it. 

What I mean the application code had to read from the socket several times
to get the entire packet and reassemble it, before passing it to the BGP
state 
machine.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 11:26 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > Part I.
> > 
> > Technical Comments:
> > ===================
> > 1. P.6  section 4. Message Formats, its possible for the 
> source BGP peer IP
> > layer to fragment a message such that the receiving BGP 
> peer socket layer
> > would have to reassemble it. Need to mention this, since 
> BGP implementations
> > are required to do this.  
> 
> *BGP* implementations are *not* required to perform any 
> message reassembly.
> (remember this is BGP spec, not TCP and/or IP spec).
> 
> Yakov.
>

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Sep 2002 08:36:47 -0700

Ben,

> state machine.

This is purely an *implementation* issue, and as such is not
subject to standardization.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Wed, 11 Sep 2002 17:40:00 +0200

Yakov, Ben-

 I thought section 6.2 "Processing Messages on a Stream Protocol"
 actually talked about these things...

-- 
Alex

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2002 16:07:53 -0400

In message <[email-masked]>, 

Ben,

This is C network coding 101.  It doesn't need to be in the spec.  If
you know how to write C code for sockets for any purpose, it can be
applied to BGP.

We also shouldn't have to specify that writes should be non-blocking.

We also don't need to specify that you should watch for EWOULDBLOCK on
writes and that some OS retrun EAGAIN instead.

We also don't need to specify that EWOULDBLOCK is broken on some
versions of some OS (not an *ix) and doesn't write anything if the
whole write doesn't fit in the available socket buffer.

We don't need to explain that after a partial read rather than hang on
the socket waiting for more input you should use the select system
call, or the poll system call for sys5ish OS, or whatever m$soft uses.

... etc.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2002 16:30:11 -0400

>  actually talked about these things...

A you suggesting we turn the terse reminder in the appendix into a
full TCP programming tutorial?

Maybe we should just change that section to.

  6.2  Processing Messages on a Stream Protocol

     BGP uses TCP as a transport mechanism.  If you are unsure as to
     how to handle asynchronous reads and writes on TCP sockets please
     refer to Unix Network Programming [RWStevens] or other
     introductory text for programming techniques for the operating
     system and TCP implementation that you are using.

That would save having to rewrite major parts of Stevens work into the
BGP spec.

Curtis

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Sep 2002 13:32:00 -0700

Curtis,

> That would save having to rewrite major parts of Stevens work into the

Seems like an excellent suggestions !!!

Yakov.

---

From: Justin Fletcher <[email-masked]>
Date: 11 Sep 2002 14:00:35 -0700

> That would save having to rewrite major parts of Stevens work into the

Perhaps the entire section should be deleted as beyond scope.

Justin Fletcher

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Sep 2002 14:03:37 -0700

Justin,

> Perhaps the entire section should be deleted as beyond scope.

That would be fine too.

Yakov.