Subject: RE: issue 32.1

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

Natale:

General Comment below

> -----Original Message-----
> From: Natale, Jonathan [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 12:25 PM
> To: 'Jeffrey Haas'; [email-masked]
> Cc: [email-masked]; Natale, Jonathan; 'Yakov Rekhter';
> [email-masked]
> Subject: RE: issue 32.1
> 
> 
> SUMMARY:
> 
> 1) we all agree that an rfc904 reference is in order.
> 
> 
> 2) EGP is already flagged as historical, and all current 
> implementations
> still support ORIGIN=EGP, so deprecating this is not that 
> important, but I
> think we already had a consensus to deprecate it.
> 
> 
> 3) I stand by my original assertion the IGP ~= route was explicitly
> introduced and INCOMPLETE ~= implicitly introduced.  This reflects the
> network command and the redistribute command.  This reflects a larger
> percentage of implementations (aka "working code").  The 
> current definitions
> leave people scratching there heads.  The current consensus 
> seems to be to
> not change these definitions.  :-(
> 
> 
> 4) I almost agree with Curtis that adding ~= "unless 
> configured to do so" is
> going to clutter up the doc, but "configured" is already in the doc 19
> times.  BGP is highly configuration dependant, get over it.  
> Not sure what
> the consensus on this is.
> 
It seems that everytime we have a problem we can't solve, we add a
configuration parameter to address it. I am in favour of trying to 
minimize the configuration parameters and maximize the correctness of 
the design.

Ben
> 
> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]] 
> Sent: Monday, September 30, 2002 11:43 AM
> To: [email-masked]
> Cc: [email-masked]; Natale, Jonathan; 'Yakov Rekhter'; 
> [email-masked]
> Subject: Re: issue 32.1
> 
> On Fri, Sep 27, 2002 at 11:51:44AM -0700, 
> [email-masked]
> wrote:
> > 		  1	    EGP - Network Layer Reachability Information
> > 				learned via the EGP protocol [RFC904]
> > 
> > That would clarify that we're talking about the protocol, 
> and not the
> > class-of-protocols, or EBGP.  It would leave unstated that 
> this could
> > theoretically be used to muck with route selection.  I think that is
> > ok.  If operators want to override ORIGIN to affect some hoho magic,
> > they are welcome to do so, but I don't think it needs to be 
> documented
> > in the base spec.
> 
> I'm cool with this.
> 
> > Andrew
> 
> -- 
> Jeff Haas 
> NextHop Technologies
>

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 30 Sep 2002 10:20:48 -0700

Ben,

> minimize the configuration parameters and maximize the correctness of 

With this in mind would you agree on the following for 5.1.1:

   ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
   is generated by the BGP speaker that originates the associated BGP
   routing information. The attribute shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this information
   to other BGP speakers. 

Yakov.