Subject: RE: admin dist/gp spec proposal

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 10:56:35 -0400

Natale:
  Sorry, I should have been more precise on whether it was EBGP or IBGP .vs.
IGP or Static. But you get my point, right?

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[email-masked]]
> Sent: Friday, September 06, 2002 10:54 AM
> To: [email-masked]
> Subject: admin dist/gp spec proposal
> 
> 
> Add sect. in bgp draft stating that ebgp routes should be 
> preferred over any
> igp routes and any igp routes should be preferred over ibgp 
> routes.  The
> exception to this is igp summary routes may be preferred over 
> ebgp routes.
> 
> PS
> RFC1812 needs to be updated and brought to a STANDARD level 
> (it discusses
> admin. Dist. concept, but does not say the obvious-- 
> connected preferred
> over static preferred over dynamic, etc.)  
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 6 Sep 2002 11:17:19 -0400

More terms that need to be defined--is static/direct an IGP? I think they
are, so I need to add other exceptions to my statement below--static is
preferred over all other protocols except direct.  Again, this should be in
1812, but it is not...(another discusson...)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Friday, September 06, 2002 10:57 AM
To: 'Natale, Jonathan'; [email-masked]
Subject: RE: admin dist/gp spec proposal

Natale:

Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 12:05:10 -0400

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Friday, September 06, 2002 11:48 AM
> To: Abarbanel, Benjamin
> Cc: 'Mathew Richardson'; Natale, Jonathan; [email-masked]
> Subject: Re: admin dist/gp spec proposal
> 
> 
> On Fri, Sep 06, 2002 at 11:39:02AM -0400, Abarbanel, Benjamin wrote:
> > Clearly the BGP and non-BGP route competition for dominance 
> in the routing
> > table is firstly, defaulted and secondly policy 
> over-written by a local
> > router administrator.  Just some mention of operational 
> impact by turning 
> > some policy knobs and changing certain route selection 
> decisions and their 
> > control plane impacts will be nice. Maybe this belongs in a 
> different spec.
> > 
> > I find spreading the knowledge across many specs a bit inconvenient.
> 
> : 9.4 Originating BGP routes
> : 
> :    A BGP speaker may originate BGP routes by injecting routing
> :    information acquired by some other means (e.g. via an 
> IGP) into BGP.
> :    A BGP speaker that originates BGP routes shall assign 
> the degree of
> :    preference to these routes by passing them through the Decision
> :    Process (see Section 9.1). These routes may also be 
> distributed to
> :    other BGP speakers within the local AS as part of the 
> update process
> :    (see Section 9.2). The decision whether to distribute non-BGP
> :    acquired routes within an AS via BGP or not depends on the
> :    environment within the AS (e.g. type of IGP) and should 
> be controlled
> :    via configuration.
>
 
What I meant is, by changing the routing table policy for priority
preference of each route type (IBGP, EBGP, Static, Direct, OSPF, ISIS, etc.)
in the routing table can lead to unstable and unpredictable control plane
behavior.  Although, if all the routers in the AS are changed accordingly,
it will minimize the instability. Again, maybe this belongs somewhere else,
RFC1812, etc. Maybe some mention of this fact would be nice.

P.S. If its already covered somewhere, ignore the suggestion.

Ben

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 6 Sep 2002 14:32:42 -0400

Ok, I agree with you, but I figured I'd throw it out there anyway...

What year is 1812 going to be updated?

:-)

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Friday, September 06, 2002 2:31 PM
To: Natale, Jonathan
Cc: [email-masked]
Subject: Re: admin dist/gp spec proposal 

Natale,

> Sent: Friday, September 06, 2002 1:49 PM
> To: 'Natale, Jonathan'
> Jonathan:
> Forward this message to the IDR list. I think we dropped off.
> 
> Ben
> 
> > Sent: Friday, September 06, 2002 1:46 PM
> > To: 'Abarbanel, Benjamin'
> > I agree.  The default values of the various protocols as they 
> > are currently
> > implemented make sense:
> > Connected
> > Static
> > Ebgp
> > Igp's
> > Ibgp
> > 
> > ...they should be documented in 1812 ideally, but putting it 
> > in 1771 would
> > not hurt.  Added a phrase to indicate that they may be user 
> > configurable is
> > good too.

Perhaps it is time to update 1812. But let's not use BGP
spec as a replacement for updating 1812 - it is not.

Yakov.

> > Sent: Friday, September 06, 2002 11:39 AM
> > To: 'Mathew Richardson'; Natale, Jonathan
> > Cc: [email-masked]
> > > > Natale, Jonathan <[email-masked]> [Fri, Sep 06, 
> > > 2002 at 10:53:40AM -0400]:
> > > >exception to this is igp summary routes may be preferred 
> > > over ebgp routes.
> > > 
> > > The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> > > BGP and non-BGP routes interact, I suspect that that really 
> > > should remain
> > > largely a local policy matter.  A BCP is probably in order (does one
> > > on this topic already exist?)
> > >
> > table is firstly, defaulted and secondly policy over-written 
> > by a local
> > IMHO,

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 15:01:12 -0400

Yakov:
  There is no reference to RFC1812 in the reference section nor references 
to this spec where appropriate in the BGP relevant discussions. As was 
earlier mentioned. At least we need to tie the thread between the two
specs so people know what the assumptions are.  

BTW. BGP Identifier is a very misleading way of naming what we know as the
Router ID in all other protocols. I would like to suggest we enhance its 
description as follows:

Current statement:
==================
"BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer. "

New Statement:
==============
"BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier also known as the Router-ID, to an IP address assigned 
         to that BGP speaker. The value of the BGP Identifier is 
         determined on startup and is the same for every local interface 
         and every BGP peer and other IP related protocols. See [x],[y] for 
         more details on Router-ID useage between BGP and other protocols."

Where x = RFC1403,
      y = RFC1745

Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 15:28:32 -0400

> 
> > I would like to rephrase my statement on one sentence.
> > 
> > " BTW. BGP Identifier is a vague way of naming what we know as the
> >   Router-ID in all other IP related protocols."
> 
> This is *technically* incorrect. 
>
Is there a case where the BGP Identifier, should or must be different than
the Router-ID for the routing system to work correctly?

Ben

> > > Sent: Friday, September 06, 2002 3:01 PM
> > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > Cc: [email-masked]

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 6 Sep 2002 15:29:43 -0400

"IP address assigned to that BGP speaker" is misleading.

Current implementation(s):
ID can be any 32 bit number except martians (0.0.0.0 255.255.255.255
127.x.x.x.x) and multicasts (>=224).x.x.x (it does NOT need to be an
interface's IP)

It may or may not be the same as other routing protocol's (OSPF) ID.

Changing it manually will cause all peers to be reset (without any warning).

Will be elected as... (should be a local matter, so I'll skip the details)

What I would like to see:
1 and only 1 router id per router (for all protocols) which is set equal to
the 1 and only 1 circuitless ip address(Bay/Wellfleet term, aka cisco
"loopback"--a term I don't like since it is often confused with loopback
address 127.x.x.x) which is an address officially assigned to the box (e.g.
no rfc1918/"private address", martian, nor multicast allowed) which cannot
be changed unless all routing protocols are restarted (obviously the admin
should be warned of this restart).

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Friday, September 06, 2002 3:01 PM
To: 'Yakov Rekhter'; Natale, Jonathan
Cc: [email-masked]
Subject: RE: admin dist/gp spec proposal 

Yakov:

Current statement:
==================
"BGP Identifier:

New Statement:
==============
"BGP Identifier:

Where x = RFC1403,
      y = RFC1745

Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 15:38:07 -0400

> 
> Not that I am aware of.  There certainly is a case where they 
> must be the
> same (cisco bgp w/ ospf, don't know all the details of 
> how/why).  

RFC1745, and RFC1403 tell you why they must be the same.

> Maybe the local admin method of numbering is more versatile by allowing 
> them to be different.  I think they should MUST be the same and in some 
> implementation they are (gated, bay).
> 
> Sent: Friday, September 06, 2002 3:29 PM
> To: 'Yakov Rekhter'; Abarbanel, Benjamin
> Cc: Natale, Jonathan; [email-masked]
> over-written

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 15:42:58 -0400

This is out of RFC1403:

"3. BGP Identifier and OSPF router ID

   The BGP identifier MUST be the same as the OSPF router id at all
   times that the router is up.

   This characteristic is required for two reasons."

This is out of RFC1745:

"3. BGP/IDRP Identifier and OSPF router ID

   The BGP/IDRP identifier MUST be the same as the OSPF router id at all
   times that the router is up."

Ben

> From: Abarbanel, Benjamin 
> Sent: Friday, September 06, 2002 3:38 PM
> To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> Cc: [email-masked]

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 6 Sep 2002 15:50:03 -0400

Possibly in 1812 (next life???)

:-)

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Friday, September 06, 2002 3:48 PM
To: Natale, Jonathan
Subject: Re: admin dist/gp spec proposal

On Fri, Sep 06, 2002 at 01:54:23PM -0400, Natale, Jonathan wrote:
> Right.  The bgp route will be the active route in the routing table
> precisely because it (the ebgp learn route) has a lower admin dist than
the
> igp learned route (which it would have got from the other bgp router (both
> bgp routers redistribute the route to igp so both also receive it via
igp)).

Oh.  Thats what I thought.

I never had much cause to inject my bgp routes into my igp so some
of the consequences of that didn't make sense.

In discussing this with Matt, we seem to agree that talking about
this in some document makes sense, but not in the base document.
Do you agree?

-- 
Jeff Haas 
NextHop Technologies

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 15:51:37 -0400

So how can I be technically incorrect?

Ben

> > Is there something that replaces them to go to for 
> technical correctness?
> 
> not to my knowledge.
> 
> Yakov.
> 
> > 
> > > Sent: Friday, September 06, 2002 3:43 PM
> > > To: Natale, Jonathan
> > > Cc: 'Abarbanel, Benjamin'; [email-masked]
> > > > 1745 and 1403 are historic
> > > 
> > > correct. And with this in mind I would suggest we stop 
> > > reference/pointing
> > > to them.
> > > 
> > > Yakov.
> > > 
> [mailto:[email-masked]] 
> [mailto:[email-masked]] 
> > > > > [mailto:[email-masked]]
> > > > > > > >   There is no reference to RFC1812 in the 
> reference section 
> > > > > > > > nor references 
> > > > > > > > BTW. BGP Identifier is a very misleading way of 
> naming what 
> > > > > > > > we know as the
> > > > > > > > Router ID in all other protocols. I would like to 
> > > suggest we 
> > > > > > > > enhance its 
> > > > > > > > description as follows:
> > > > > > > > 
> > > > > > > > Current statement:
> > > > > > > > ==================
> > > > > > > > "BGP Identifier:
> > > > > > > 
> > > > > > > >          Identifier to an IP address assigned 
> to that BGP 
> > > > > > > > speaker.  The
> > > > > > > >          value of the BGP Identifier is determined 
> > > on startup 
> > > > > > > > and is the
> > > > > > > >          This 4-octet unsigned integer 
> indicates the BGP 
> > > > > > Identifier of
> > > > > > > >          Identifier also known as the 
> Router-ID, to an IP 
> > > > > > > > address assigned 
> > > > > > > >          determined on startup and is the same 
> for every 
> > > > > > > > local interface 
> > > > > > > >          and every BGP peer and other IP 
> related protocols. 
> > > > > > > > See [x],[y] for 
> > > > > > > >          more details on Router-ID useage 
> between BGP and 
> > > > > > > > other protocols."
> > > > > > > > 
> > > > > > > > Where x = RFC1403,
> > > > > > > >       y = RFC1745
> > > > > > > > 
> > > > > > > > Ben
> > > > > > [mailto:[email-masked]] 
> > > > > > > [mailto:[email-masked]] 
> > > > > > > > > > > >igp routes and any igp routes should be 
> preferred 
> > > > > > over ibgp 
> > > > > > > > > > routes.  The
> > > > > > > > > > > largely a local policy matter.  A BCP is 
> probably in 
> > > > > > > > order (does one
> > > > > > > > > > I find spreading the knowledge across many 
> specs a bit 
> > > > > > > > inconvenient.
> > > > > > > > > > 
> > > > > > > > > > IMHO,
> > > > > > > > > > Ben
> > > > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > 
> > > 
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 6 Sep 2002 15:52:28 -0400

That's what I was going to say.  Maybe this can be slated for rfc1812 [in
the next life].

:-)

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Friday, September 06, 2002 3:48 PM
To: Abarbanel, Benjamin
Cc: Natale, Jonathan; [email-masked]
Subject: Re: admin dist/gp spec proposal 

> Is there something that replaces them to go to for technical correctness?

not to my knowledge.

Yakov.

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 9 Sep 2002 10:16:54 -0400

Can someone on this list tell me, why BGP Identifier must be defined
differently
than the Router ID, and show some examples where its technically sensible to
diverge it from the Router ID?

Ben

> From: Manav Bhatia [mailto:[email-masked]]
> Sent: Monday, September 09, 2002 4:00 AM
> To: Yakov Rekhter; Natale, Jonathan
> Yakov and others,
> draft-ietf-isis-traffic-04.txt states that if some router 
> advertises the
> router ID TLV (containing the 4-octet router ID of the router 
> originating
> the LSP) in its LSP, and if it also advertises BGP routes 
> with the BGP next
> hop set to the BGP router ID (which is what is usually done), 
> then in such
> cases, the TE router ID should match the BGP router ID.
> 
> I think this warrants the need to mention that the BGP Router 
> ID *should*
> match the Router ID as used by the other routing protocols. 
> Moreover i dont
> see any need for the router IDs to *not* match for the BGP 
> and IGPs and i
> am sure that there will not be any operators assigning 
> different Router IDs
> for the same.
> 
> Or am i missing something here?
> 
> Manav
> 
> ----- Original Message -----
> From: "Yakov Rekhter" <[email-masked]>
> To: "Natale, Jonathan" <[email-masked]>
> Cc: "'Abarbanel, Benjamin'" <[email-masked]>;
> <[email-masked]>
> Sent: Saturday, September 07, 2002 1:13 AM
> | Natale,
> |
> | > 1745 and 1403 are historic
> |
> | correct. And with this in mind I would suggest we stop 
> reference/pointing
> | to them.
> |
> | Yakov.
> |
> | > -----Original Message-----
> | > From: Abarbanel, Benjamin [mailto:[email-masked]]
> | > Sent: Friday, September 06, 2002 3:38 PM
> | > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> | > Cc: [email-masked]
> | > Subject: RE: admin dist/gp spec proposal
> | >
> | >
> | >
> | > >
> | > > Not that I am aware of.  There certainly is a case where they
> | > > must be the
> | > > same (cisco bgp w/ ospf, don't know all the details of
> | > > how/why).
> | >
> | > RFC1745, and RFC1403 tell you why they must be the same.
> | >
> | > > Maybe the local admin method of numbering is more versatile by
> allowing
> | > > them to be different.  I think they should MUST be the 
> same and in
> some
> | > > implementation they are (gated, bay).
> | > >
> | > > -----Original Message-----
> | > > From: Abarbanel, Benjamin 
> | > > Sent: Friday, September 06, 2002 3:29 PM
> | > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> | > > Cc: Natale, Jonathan; [email-masked]
> | > > Subject: RE: admin dist/gp spec proposal
> | > >
> | > >
> | > > >
> | > > > > I would like to rephrase my statement on one sentence.
> | > > > >
> | > > > > " BTW. BGP Identifier is a vague way of naming what 
> we know as
> the
> | > > > >   Router-ID in all other IP related protocols."
> | > > >
> | > > > This is *technically* incorrect.
> | > > >
> | > > Is there a case where the BGP Identifier, should or must be
> | > > different than
> | > > the Router-ID for the routing system to work correctly?
> | > >
> | > > Ben
> | > >
> | > >
> | > > >
> | > > > >
> | > > > >
> | > > > > > -----Original Message-----
> | > > > > > From: Abarbanel, Benjamin
> | > > [mailto:[email-masked]]
> | > > > > > Sent: Friday, September 06, 2002 3:01 PM
> | > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> | > > > > > Cc: [email-masked]
> | > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > >
> | > > > > >
> | > > > > > Yakov:
> | > > > > >   There is no reference to RFC1812 in the 
> reference section
> | > > > > > nor references
> | > > > > > to this spec where appropriate in the BGP relevant
> | > > > > > discussions. As was
> | > > > > > earlier mentioned. At least we need to tie the thread
> | > > > between the two
> | > > > > > specs so people know what the assumptions are.
> | > > > > >
> | > > > > > BTW. BGP Identifier is a very misleading way of 
> naming what
> | > > > > > we know as the
> | > > > > > Router ID in all other protocols. I would like to 
> suggest we
> | > > > > > enhance its
> | > > > > > description as follows:
> | > > > > >
> | > > > > > Current statement:
> | > > > > > ==================
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier to an IP address assigned to that BGP
> | > > > > > speaker.  The
> | > > > > >          value of the BGP Identifier is 
> determined on startup
> | > > > > > and is the
> | > > > > >          same for every local interface and every 
> BGP peer. "
> | > > > > >
> | > > > > > New Statement:
> | > > > > > ==============
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier also known as the Router-ID, to an IP
> | > > > > > address assigned
> | > > > > >          to that BGP speaker. The value of the BGP
> | > > Identifier is
> | > > > > >          determined on startup and is the same for every
> | > > > > > local interface
> | > > > > >          and every BGP peer and other IP related 
> protocols.
> | > > > > > See [x],[y] for
> | > > > > >          more details on Router-ID useage between BGP and
> | > > > > > other protocols."
> | > > > > >
> | > > > > > Where x = RFC1403,
> | > > > > >       y = RFC1745
> | > > > > >
> | > > > > > Ben
> | > > > > > > -----Original Message-----
> | > > > > > > From: Yakov Rekhter [mailto:[email-masked]]
> | > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> | > > > > > > To: Natale, Jonathan
> | > > > > > > Cc: [email-masked]
> | > > > > > > Subject: Re: admin dist/gp spec proposal
> | > > > > > >
> | > > > > > >
> | > > > > > > Natale,
> | > > > > > >
> | > > > > > > >
> | > > > > > > >
> | > > > > > > > -----Original Message-----
> | > > > > > > > From: Abarbanel, Benjamin
> | > > > [mailto:[email-masked]]
> | > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> | > > > > > > > To: 'Natale, Jonathan'
> | > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > >
> | > > > > > > > Jonathan:
> | > > > > > > > Forward this message to the IDR list. I think we
> | > > dropped off.
> | > > > > > > >
> | > > > > > > > Ben
> | > > > > > > >
> | > > > > > > > > -----Original Message-----
> | > > > > > > > > From: Natale, Jonathan 
[mailto:[email-masked]]
| > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
| > > > > > > > > To: 'Abarbanel, Benjamin'
| > > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > > >
| > > > > > > > >
| > > > > > > > > I agree.  The default values of the various
| > > > protocols as they
| > > > > > > > > are currently
| > > > > > > > > implemented make sense:
| > > > > > > > > Connected
| > > > > > > > > Static
| > > > > > > > > Ebgp
| > > > > > > > > Igp's
| > > > > > > > > Ibgp
| > > > > > > > >
| > > > > > > > > ...they should be documented in 1812 ideally, but
| > > > putting it
| > > > > > > > > in 1771 would
| > > > > > > > > not hurt.  Added a phrase to indicate that they
| > > may be user
| > > > > > > > > configurable is
| > > > > > > > > good too.
| > > > > > >
| > > > > > > Perhaps it is time to update 1812. But let's not use BGP
| > > > > > > spec as a replacement for updating 1812 - it is not.
| > > > > > >
| > > > > > > Yakov.
| > > > > > >
| > > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Abarbanel, Benjamin
| > > > > [mailto:[email-masked]]
| > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
| > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
| > > > > > > > Cc: [email-masked]
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > >

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 9 Sep 2002 16:15:27 -0400

Jeff:

> 
> On Mon, Sep 09, 2002 at 02:45:11PM -0400, Abarbanel, Benjamin wrote:
> > The only thing I want to add about the definition of the 
> BGP Identifier, if 
> > we choose to keep it separate from the Router-ID, is that 
> its value should
> > be
> > a routable/reachable IP address in the network where BGP operates.
> 
> Two comments:
> 1. If its v6 only, there may be no v4 address to reach.

Then the value should be routable in the IPv6 Cloud. The router that has
a dual stack should have two values for the BGP Identifier, one for IPv4
which is common across all routing protocols, and one for IPv6 also common
across all routing protocols. The BGP router should know based on operator 
configuration, what address family its peer is using and use it accordingly.

> 2. While it is a *nicety* that we can use the identifier in the one
>    place it shows up globally (aggregator) to determine what router
>    did the work, the only requirement is that it be a valid 
> BGP Identifier
>    for purposes of dealing with loop detection and route selection.
> 

Dont forget Interworking with other protocols. 

> However, if its going to be ipv4, it doesn't hurt to recommend that it
> have a real IP address.  Note that it might very well be a rfc1918 
> address.
> 
> > Ben
> 
> -- 
> Jeff Haas 
> NextHop Technologies
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 9 Sep 2002 17:53:01 -0400

Agreed.

Ben

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, September 09, 2002 5:44 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; Natale, Jonathan; [email-masked]
> In message 
> <[email-masked]>, 
> "Abarbanel, Benjamin" writes:
> > 
> >          ... The value of the BGP Identifier is 
> This is not true so we can't add it.  The OSPF router-id and BGP
> Identifier can be different (the OSPF router id need not be a routable
> address and the BGP Identifier must be a routable address).  It is a
> good idea to make the OSPF router-id routable and make it the BGP
> Identifier take on the same value but not a requirement.
> 
> Curtis
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 9 Sep 2002 18:15:56 -0400

I was stuck in the BGP world too long. I forgot that OSPF has a non-routable
Router-ID address. I do remember that the OSPF TE router address must be
routable in its TE extensions, though.

ISIS SYSTEM ID does not count, but the IPv4/IPv6 TE router-ID for it in the
TE
extensions must be routable right? 

a little excerpt from ISIS TE spec:

"6.0 The Traffic Engineering router ID TLV

   The Traffic Engineering router ID TLV is TLV type 134.

   The router ID TLV contains the 4-octet router ID of the router
   originating the LSP.  This is useful in several regards:

   For traffic engineering, it guarantees that we have a single stable
   address that can always be referenced in a path that will be
   reachable from multiple hops away, regardless of the state of the
   node's interfaces.

   If OSPF is also active in the domain, traffic engineering can compute
   the mapping between the OSPF and IS-IS topologies.

   If a router advertises the Traffic Engineering router ID TLV in its
   LSP, and if it advertises BGP routes with the BGP next hop attribute
   set to the BGP router ID, in that case the Traffic Engineering router
   ID should be the same as the BGP router ID.

   Implementations MUST NOT inject a /32 prefix for the router ID into
   their forwarding table, because this can lead to forwarding loops
   when interacting with systems that do not support this TLV."

Ben

P.S. The problem is we have too many different ways to do this. We should
have
one method and one mechanism it will make interworking with other protocols
much
more simpler to do.

> Sent: Monday, September 09, 2002 5:58 PM
> To: Natale, Jonathan
> Cc: 'Abarbanel, Benjamin'; 'Yakov Rekhter'; [email-masked]
> <[email-masked]
> ks.com>, "Natale, Jonathan" writes:
> > > > 
> No, but you can configure then to be different and things still do
> work.  One possible reason to configure them differently would be if
> your IGP was ISIS and the router ID was an NSAP, not supported by BGP
> as a BGP Identifier.  Another is you have an existing OSPF network and
> want to add BGP and your OSPf routers were numbered sequentially
> (router IDs are not routable).
> 
> Curtis
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 9 Sep 2002 18:17:20 -0400

> These documents are both historic.  In a prior message I mentioned but
> did not give the details as to why this practice (injecting BGP into
> OSPF ala RFC1745) could be extremely harmfull.
> 
> Curtis

I agree about BGP into OSPF, but what about the other way around?

Ben

---

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 10 Sep 2002 08:21:10 -0400

I propose that any 32bit number be accepted as the received
id/aggregator/etc. but disallow the user from locally setting the
id/aggregator/etc to a non-valid host address (0.0.0.0, 255.255.255.255,
127.x.x.x, (>=224.x.x.x) since some implementation may not peer with these
numbers (due to RFC1771 compliance).

I also think it should [still] be recommended to locally set the bgp id ==
the ospf id == a (preferably globally/officially assigned)
circuitless/boxwide/loopback address, and that this should be
configured/implemented such that a reboot will not change the number.

-----Original Message-----
From: Enke Chen [mailto:[email-masked]] 
Sent: Saturday, September 07, 2002 2:50 AM
To: Jeffrey Haas
Cc: [email-masked]; [email-masked]
Subject: Re: admin dist/gp spec proposal 

Jeff:

> Date: Fri, 6 Sep 2002 16:05:02 -0400
> From: Jeffrey Haas <[email-masked]>
> Message-ID: <[email-masked]>
> References:
<[email-masked]>

[snip]

> I should also point out that we have had the BGP Identifier arguments
> before.  We are trending this away from an actual IP to just an
> Identifer, which makes usage of it in ipv6 networks easier.

Indeed, and please take note of the IDR WG draft on the BGP Identifier:

     draft-ietf-idr-bgp-identifier-00.txt

-- Enke

---

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 10 Sep 2002 09:23:50 -0400

Er, "it SHOULD mention that", sorry for the typo.

-----Original Message-----
From: Natale, Jonathan [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2002 9:19 AM
To: [email-masked]
Subject: RE: admin dist/gp spec proposal

I agree, it mention that the BGP Router ID *should*
match the Router ID as used by the other routing protocols.

Let's here the reasons why it should not be mentioned (other than the
draconian fact that this is a bgp and only bgp spec)...

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]] 
Sent: Monday, September 09, 2002 4:00 AM
To: Yakov Rekhter; Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; [email-masked]
Subject: Re: admin dist/gp spec proposal

Yakov and others,
draft-ietf-isis-traffic-04.txt states that if some router advertises the
router ID TLV (containing the 4-octet router ID of the router originating
the LSP) in its LSP, and if it also advertises BGP routes with the BGP next
hop set to the BGP router ID (which is what is usually done), then in such
cases, the TE router ID should match the BGP router ID.

I think this warrants the need to mention that the BGP Router ID *should*
match the Router ID as used by the other routing protocols. Moreover i dont
see any need for the router IDs to *not* match for the BGP and IGPs and i
am sure that there will not be any operators assigning different Router IDs
for the same.

Manav

----- Original Message -----
From: "Yakov Rekhter" <[email-masked]>
To: "Natale, Jonathan" <[email-masked]>
Cc: "'Abarbanel, Benjamin'" <[email-masked]>;
<[email-masked]>

| Natale,
|
| correct. And with this in mind I would suggest we stop reference/pointing
| > > them to be different.  I think they should MUST be the same and in
| > > From: Abarbanel, Benjamin [mailto:[email-masked]]
| > > > > " BTW. BGP Identifier is a vague way of naming what we know as
| > > > > >   There is no reference to RFC1812 in the reference section
| > > > > > BTW. BGP Identifier is a very misleading way of naming what
| > > > > > Router ID in all other protocols. I would like to suggest we
| > > > > >          value of the BGP Identifier is determined on startup
| > > > > >          same for every local interface and every BGP peer. "
| > > > > >          and every BGP peer and other IP related protocols.
| > > > > > > > > From: Natale, Jonathan [mailto:[email-masked]]

---

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 10 Sep 2002 09:58:28 -0400

Isn't that what "SHOULD" means???

Why does it need to be routable?

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Monday, September 09, 2002 5:44 PM
To: Abarbanel, Benjamin
Cc: 'Yakov Rekhter'; Natale, Jonathan; [email-masked]
Subject: Re: admin dist/gp spec proposal 

In message

Curtis

---

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 10 Sep 2002 10:05:25 -0400

12.0.0.1 is not the loopback
127.0.0.1 is 1 loopback. Any 127.x.x.x is a loopback.  
I think you missed the point.  The IOS loopback interface != IP loopback
address.
I agree, there may be more than 1 id, buut why would you.  Again, the word
is "SHOULD" (not "MUST").  Or are you proposing that only musts be added???

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Monday, September 09, 2002 5:55 PM
To: Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; [email-masked]'
Subject: Re: admin dist/gp spec proposal 

In message
<[email-masked]
> should be warned of this restart).

FYI - loopback is the name derived from BSD and the loopback address
has the address of 12.0.0.1 plus at least one alias if the BSD host
has more than one interface and supports specific applications which
can bind the client (connect rather than listen/accept) side of a TCP
connection to the loopback.  A corrent IBGP implementation is one such
application.  Circuitless was later invented by clueless over at Bay
rather than using existing and long standing terminology (I was Bay's
main BGP customer at the time so I can say that as much as anyone).

There is no requirement for 1 and only 1 router id per router.  Get
used to it.  It is considered best practice though.

Curtis

---

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 10 Sep 2002 10:08:42 -0400

Ok, good examples.  But they still should be the same. (this horse is dead)

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Monday, September 09, 2002 5:58 PM
To: Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; 'Yakov Rekhter'; [email-masked]
Subject: Re: admin dist/gp spec proposal 

In message

Curtis

---

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 10 Sep 2002 10:12:05 -0400

"If the matching route is learned from an OSPF neighbor, its OSPF router ID
must match the BGP router ID of the iBGP neighbor."
-- http://www.cisco.com/warp/public/459/25.shtml

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Monday, September 09, 2002 6:11 PM
To: Abarbanel, Benjamin
Cc: 'Natale, Jonathan'; 'Yakov Rekhter'; [email-masked]
Subject: Re: admin dist/gp spec proposal 

In message
<[email-masked]>, 

Curtis

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 10 Sep 2002 10:49:42 -0400

Curtis:
  The comment I made was as a response to a joke message posted. I think
you are reading these messages out of sequence. I realize you are trying
to catch up with a bunch of messages posted in the past few days.

On a second note, the ADs had posted an invitation to all IDR list members
to review the latest RFC1771 draft, called "draft-ietf-idr-bgp4-17.txt".
Some people are new to this list and are giving the spec its most fresh
and open minded review possible. After all that is what the ADs asked for,
at the end of this effort, hopefully the spec would be much more user
friendly and correct as to current implemenatations, and properly states
what is, should, and must be done in BGP.

Ben

> Sent: Monday, September 09, 2002 6:28 PM
> To: Abarbanel, Benjamin
> Cc: 'Natale, Jonathan'; 'Jeffrey Haas'; [email-masked]
> <[email-masked]>, 
> > This is turning into a joke, do we want to tie loose ends or not?
> > 
> > :-)
> 
> 
> Yes but we don't want to put nonsense into the document.  Some of us
> have been looking at BGP4 for over 8 years and do try to remain
> patient with newbies.  When the newbies are clueless, return to
> discussions that occurred and were resolved years ago, and vigorously
> make incorrect assertions it makes it harder to maintain patience.
> We're doing just fine so far.  :-)
> 
> Curtis
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 10 Sep 2002 11:40:07 -0400

> From: Russ White [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 11:13 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'; 'Yakov Rekhter'; Natale, Jonathan;
> [email-masked]
> > Could you give me an example where 2 BGP processes interact
> > with 1 OSPF process. Also an example where 2 OSPF processes
> > interact with 1 BGP Process.
> 
> The second is more plausible. I won't say it's common, but it is
> very possible on every implementation I know of. For instance,
> I've seen networks with two OSPF processes terminating in a
> single router, with redistribution, and a single BGP process on
> top of both. It would be simple to set up:
> 
> !
> router bgp 100
>  <stuff here>
> !
> router ospf 100
>  <stuff here>
> !
> router ospf 200
>  <stuff here>
> 
> Another instance to consider is on a PE, where I would think this
> could be very common. You're carrying multiple OSPF instances to
> customers, and then a "real" igp instance for your internal
> cloud, and then a single bgp instance. Does it matter if all
> these instances share the same router id, or not? In practice,
> they never have.
> 
> It appears that setting up a requirement that the router id's in
> all routing processes, for this and other reasons (such as the
> instance given of IS-IS with longer router id's), simply isn't
> possible.
> 
> :-)
> 
> Russ
> 
> 
As a PE you are talking about VPNs, using the same Router ID for each
OSPF instance in each VPN. That should not pose any problems, should it?

Since your example, there is a process ID defined in the config above. 
Internal to the implementation that could be used to identify which routes
belong to which instance of OSPF, even if they have the same router-ID
externally to the box. 
> 
> __________________________________
> [email-masked] CCIE <>< Grace Alone
> 
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 10 Sep 2002 13:43:10 -0400

Agreed

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 1:21 PM
> To: Abarbanel, Benjamin
> Cc: 'Russ White'; [email-masked]'; 'Yakov Rekhter'; Natale,
> Jonathan; [email-masked]
> > For me its the NMS point of view, where its the address of 
> a node which
> > is independent of a given interface and protocol and allows 
> the NMS system
> > the ability to keep track of routing information in that 
> node as well as
> > assist in keeping track which node/router owns which 
> routes. Interworking
> > and networking/reachability capabilities are biproducts of 
> this feature.
> > 
> > It seems silly to me to have one Router-ID value for BGP, 
> another value
> > for Router-ID for OSPF, a third value for ISIS and so on. 
> It makes the
> > number meaningless when view from the big cloud in the sky 
> called NMS.
> 
> Not necessaraly a problem from an NMS standpoint, a bit of a hassle to
> list multiple ID's for the same router, but not impossible.  Plus,
> most operators already have one ID for the router, before any MUSTs
> have been specified.
> 
> More importantly, let's move this to a BCP document.  Yakov has a good
> point, referencing this isn't absolutely necessary to create good,
> interoperable Base BGP implementations.  We can stick this in another
> document, and things will be a lot clearer, and we can make 
> more progress
> on getting the Base spec out.
> 
> Andrew
>