Subject: issue 17 - final resolution

From: Yakov Rekhter <[email-masked]>
Date: Tue, 21 Jan 2003 08:58:19 -0800

> 17) Section 3, Page 8, Paragraph 3 - Obsolete?
> ----------------------------------------------------------------------------
> Status: No Consensus
> Change: Potentially
> Summary: Do existing vendors rely on this, or no?  If no, remove it.
> 
> Discussion:
> 
> This issue was spawned from the discussions in issue 16, specifically:
> 
> Anonymous reviwer:
> 
>  > Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
>  > seems obsolete.
> 
> Yakov:
> 
>  I'll take it out.
> 
> With regard to this, Siva asked if some route optimizaiton vendors rely on
> this.
> 
> Jeff replied:
> 
>  To provide context, this paragraph currently reads:
> 
>  :   The hosts executing BGP need not be routers.  A non-routing host
>  :   could exchange routing information with routers via EGP [RFC904] or
>  :   even an interior routing protocol. That non-routing host could then
>  :   use BGP to exchange routing information with a border router in
>  :   another Autonomous System. The implications and applications of this
>  :   architecture are for further study.  
>   
>  There are several deployed entities that could be considered to "exploit"
>  this paragraph.  Route collectors, route servers, bandwidth shapers
>  and other optimizers.  However, the original text may be showing its
>  age a little bit.
> 
>  Perhaps the following might be a bit more appropriate:
> 
>  "The hosts executing BGP need not be routers.  A non-routing host may 
>   exchange routing information with a BGP speaker for reasons
>   that are outside the scope of this document."
>  
>  I would also propose adding to the same paragraph (but could be persuaded
>  to drop it since it is *logically* redundant):
>  "These non-routing hosts should exercise great care not to insert
>   themselves into the forwarding path if they re-announce BGP routes."
> 
> Yakov replied:
> 
>  Since operations of non-routing host are outside the scope of the
>  document, and since the document doesn't preclude non-routing hosts
>  to run BGP, I would prefer just to take the following paragraph out,
>  and not to add any new text.
> 
>    The hosts executing BGP need not be routers.  A non-routing host
>    could exchange routing information with routers via EGP [RFC904] or
>    even an interior routing protocol. That non-routing host could then
>    use BGP to exchange routing information with a border router in
>    another Autonomous System. The implications and applications of this  
>    architecture are for further study.
> 
> Jeff replied that this was ok, and instead suggested:
> 
> At the beginning of the document, we define:
>    BGP speaker
>          A router that implements BGP.
> 
>  This (potentially) restricts a speaker to being a router.
>  Additionally, several spots in the text where we probably should
>  say "BGP speaker", we use router.   
> 
> Yakov agreed to add this definition.
> 
> Jeff replied that there still was a problem with this definition being
> too limiting.  The discussion meandered off list for a couple of 
> exchanges and these additional definitions were proposed:
> 
> First Jeff proposed this:
> 
>  "A router that implements the BGP protocol.
>   Non-routing hosts that also implement BGP are out of scope of this
>   document."
> 
> Then Andrew replied, that we should make sure the definition does not
> opt out entirely from making sure that non-routing hosts are interoperable:
> 
> BGP Speaker
>     A router that implements the BGP protocol.  The internal behavior of
>     non-routing hosts that also implement BGP are out of scope of this
>     document.  However, in their interactions with routers, non-routing hosts
>     must behave as if they were routers.
> 
> And Jeff replied:
> 
> BGP Speaker
>     A router that implements the BGP protocol.  The internal behavior of
>     non-routing hosts that also implement BGP are out of scope of this
>     document.  However, in their interactions with BGP speaking routers, 
>     non-routing hosts that implement BGP should be indistinguishable from 
>     a router on the wire.
> 
>  (or something like that - s/on the wire/ with whatever sounds best.)
> 
>  IOW, look like bgp on the wire - what you do internally is out of scope.
> 
> This was discussed in the "proxy: more comments on draft -18" thread.  
> And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?"
> thread.

The current text is just fine. Since the definition of "BGP speaker"
makes it quite clear that in the context of this document it means
a router, and *not* a non-routing host implementing BGP, it follows
that the issue of non-routing hosts implementing BGP is outside
the document. 

If there is a sufficient interest to document the issues related
to non-routing hosts implementing BGP (including interaction between
these hosts and routers), then this should be done in a separate document.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Jan 2003 12:04:48 -0500

> these hosts and routers), then this should be done in a separate document.

Normalize the text to read "BGP Speaker" in the few remaining places
it says router, leave the current definition of BGP Speaker and
I yield.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 21 Jan 2003 09:17:07 -0800

Jeff,

> it says router, leave the current definition of BGP Speaker and

Accepted.

Yakov.