Subject: RE: issue 32.1

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

1) It is wrong because Network Layer Reachability Information is ALWAYS
interior to the originating AS.  What would be the "other means"???  Anyway,
this is certainly not the current use.

2) "network cmd" nor "redistribute" is mentioned in the proposed change

3) 32.1 is not significantly related to 32.2

4) I have personally witnessed many people confusing EGP with EBGP.

I stand by my proposal (which was supported by at least one other as I
recall):

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"
...
"[1] RFC904
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.

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.

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

  32) Clarify EGP Reference
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Need to clarify the EGP Reference, since there seems to be some
    confusion on the issue.
  
  Discussion:
  
  3. P. 13, EGP, are there other EGP protocols other than BGP that are in
use?
  If not, change EGP to BGP.
  
  A response to this suggested that we add a reference to [1] (the EGP
  spec) here.

This will be address as part of the response to issue 9
  
  Another reponse clarified that this refers to EGP-the-protocol and
  NOT the class.
  
  Another response disagreed, but suggested that:
  
  IGP = network was explicitly introduced into bgp (network cmd)
  INCOMPLETE = network was implicitly introduced into bgp (redistribute)
  EGP = other

I've yet to understand what is incorrect with the current text.
I also think that talking about "network cmd" and "redistribute"
makes it a bit vendor specific. Therefore, I think we should keep
the current text.
  
  The original commentor thought that this refered to EGP-the-class of
  protocols.   And why not use BGP therefore, as the only EGP.
  
  There was some disucssion over whether or not we should mention something
  that is historical.

I don't think that the BGP base spec needs to talk about the status
of EGP spec [RFC904].
  
  Jeff suggested a footnote in the Origin section about EGP.
  
  Curtis suggested that we state that the EGP in ORIGIN is depricated,
  but retain the value to document what it used to mean.
  
  This reviewer thinks a statement about whether this "EGP" origin refers
  to the protocol or the class or protocols would be useful.

From the context it should be clear that we are talking about "the EGP"
(means [RFC904]).

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Sep 2002 12:22:20 -0700

Jonathan,

> interior to the originating AS.  

Not really, as ASs can exchange their NLRI in a variety of ways other
than BGP (or for than matter EGP[RFC904]). So, NLRI that is injected
into BGP could easily be external to the AS that originates this injection.

> What would be the "other means"???  

Anything other than IGP or EGP[RFC904].

> Anyway, this is certainly not the current use.
> 

I certainly agree with you on that.

> 4) I have personally witnessed many people confusing EGP with EBGP.

We can't change the term "the EGP", as it refers to the protocol defined
in [RFC904]. Neither can we change the term "EBGP".

> I stand by my proposal (which was supported by at least one other as I

As I mentioned to you in my previous e-mail, your proposal introduces
two terms "implicitly introduced into BGP" and "explicitly introduced 
into BGP" that aren't really well-defined.

Yakov.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Sep 2002 11:24:50 -0400

In message <[email-masked]
>   32) Clarify EGP Reference

How about if we just make the simple change:

to

                  1         EGP - Network Layer Reachability Information
                               learned via the EGP protocol [1]

Administratively setting the ORIGIN is a "preference of last resort"
hack.  This won't encourage the practice but it won't prevent anyone
from allowing this deviation from the protocol or using it.

[btw - Jonathan's suggestion completely changes the meaning of this
ORIGIN code.  If we wanted to change the meaning because there was a
need, we should just make up a new attribute which fits into the route
selection where ORIGIN goes and make it an integer value to allow
degrees of "preference of last resort" rather than just one "less
prefered" value but we are not changing BGP in this way.  This of
course opens the "inconsistent route selection between implementations
of different vintage" can-o-worms.]

Curtis