Subject: RE: issue 32.1

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 25 Sep 2002 14:35:03 -0400

How about:
"5.1.1 ORIGIN
  
     ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
     shall be generated by the autonomous system that originates the
     associated routing information. Its value shall not be
     changed by any other speaker unless the other speaker is
     administratively configured to do so to affect policy
     decisions."

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2002 1:50 PM
To: [email-masked]
Subject: issue 32.1

  32.1) EGP ORIGIN Clarification
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Proposal to update the EGP ORIGIN section.
  
  Discussion:
  
  This discussion is picked up again in the "Review of
draft-ietf-idr-bgp4-17"
  thread, where specific text is proposed:
  
  Old:
  
              "ORIGIN is a well-known mandatory attribute that defines the
              origin of the path information.  The data octet can assume
              the following values:
  
                    Value		Meaning
  
                    0	    IGP - Network Layer Reachability Information
                                 is interior to the originating AS
  
                    1	    EGP - Network Layer Reachability Information
                                 learned via the EGP protocol
  
                    2	    INCOMPLETE - Network Layer Reachability
                                 Information learned by some other means"
  New:
  
              "ORIGIN is a well-known mandatory attribute that defines the
              origin of the path information.  The data octet can assume
              the following values:
  
                    Value		Meaning
  
                    0	    IGP - NLRI was explicitly introduced into bgp
  
                    1	    EGP - this value was administratively
                                 configured to affect policy decisions or
                                 NLRI was learned via the EGP protocol [1]
  
                    2	    INCOMPLETE - NLRI was implicitly introduced
                                        into bgp"
  
  since:
  1) The network command sets the origin to IGP and I remember seeing
  somewhere that only static routes should be set to IGP.
  2) The primary use of EGP value is policy
  3) EGP seems to still exist, anyway even if it does not it is
  not worth re-writing the world.

Since the current text is technically correct, and since the terms
"implicitly introduced" and "explicitly introduced" aren't really
well-defined I think we should just keep the current text.
  
  Also, change:
  "5.1.1 ORIGIN

     ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
     shall be generated by the autonomous system that originates the
     associated routing information. It shall be included in the UPDATE
     messages of all BGP speakers that choose to propagate this
     information to other BGP speakers."
  
  to:
  "5.1.1 ORIGIN
  
     The value of the ORIGIN attribute shall be set by the speaker
     that originates the associated NLRI.	 Its value shall not be
     changed by any other speaker unless the other speaker is
     administratively configured to do so to affect policy
     decisions."
  
  since:
  1) It is already defined as well-known mandatory attribute.
  2) It may be set differently within the same AS (not saying this is good).
  3) It is commonly used for policy, but by default does not get changed.
  4) Speakers have no choice, it is mandatory.

Please note that issue 33 asks for exactly the opposite. For the
sake of consistency I suggest we keep 5.1.1 as is.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 25 Sep 2002 14:43:56 -0400

>      administratively configured to do so to affect policy

"shall" may be a bit strong.

A quick question to those who have "been there, done that".
The primary purpose of ORIGIN seems to have been to bias routing
towards routes that actually came from IGP's as opposed to some
other means.  

Was there any other usage of the ORIGIN in interactions with EGP?

If not, we probably should explicitly mention its purpose in
biasing route selection.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Sep 2002 11:52:01 -0700

Jeff,

> "shall" may be a bit strong.

Agreed. So, how about if we'll use the text suggested by Jonathan,
but replace "shall" with "should".

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 25 Sep 2002 14:58:54 -0400

> but replace "shall" with "should".

I'd be happy with that, but what about the other part of my post?

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 26 Sep 2002 11:48:35 -0400

In message <[email-masked]
>      administratively configured to do so to affect policy

How about if we save time and in the definitions section we just state
that MUST means manditory except if configured to do otherwise.  That
should cover many of the objections in our list.  :-)

Or maybe we should just leave things as is and not go around adding
"unless administratively configured to do otherwise" ["to affect
policy decisions" being the most common reason for the otherwise].

Mannually changing the origin code should not be encouraged.

Curtis

---

From: [email-masked]
Date: Fri, 27 Sep 2002 11:51:44 -0700

This is the text that it seems from the discussion that we are settled on
for section 5.1.1:

----

After much continued discussion on this in the "issue 32.1" thread, we seem
to have come to a consensus that section 5.1.1 should read:

	ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
	shall be generated by the speaker that originates the
	associated routing information. Its value should not be
	changed by any other speaker unless the other speaker is
	administratively configured to do so to affect policy
	decisions."

This text met with a number of agreements, and one disagreement stating
that we shouldn't have the "unless administratively configured" portion.

----

We would still appear to be undecided on any modifications to the ORIGIN
listing.  To me, there seems to be sufficent confusion around the "EGP"
reference to merit some sort of clarification.  The simplest modification
would be to change:

to:

		  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.

Andrew

On Thu, Sep 26, 2002 at 11:48:35AM -0400, Curtis Villamizar wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> To: "Natale, Jonathan" <[email-masked]>
> Cc: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
> Reply-To: [email-masked]
> Subject: Re: issue 32.1 
> In-reply-to: Your message of "Wed, 25 Sep 2002 14:35:03 EDT."
>              <[email-masked]> 
> Date: Thu, 26 Sep 2002 11:48:35 -0400
> From: Curtis Villamizar <[email-masked]>
> Precedence: bulk
> X-OriginalArrivalTime: 26 Sep 2002 15:50:38.0014 (UTC) FILETIME=[7567BDE0:01C26574]
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 30 Sep 2002 11:43:04 -0400

> they are welcome to do so, but I don't think it needs to be documented

I'm cool with this.

-- 
Jeff Haas 
NextHop Technologies

---

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

> > they are welcome to do so, but I don't think it needs to be documented

that would be fine with me too.

Yakov.