Subject: RE: BGP - IGP Redistribution Issue

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 24 Sep 2002 11:54:47 -0400

Jeff:
  Comments below

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2002 11:29 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: Re: BGP - IGP Redistribution Issue
> 
> 
> Ben,
> 
> On Tue, Sep 24, 2002 at 11:15:09AM -0400, Abarbanel, Benjamin wrote:
> > Would it make sense to add the recommendation to RFC1772bis, in some
> > practical deployment techniques. I realize its hard to 
> undue what has been
> > cast in concrete, but at least a recommendation could be added.
> 
> As much as I would really like to incorporate some of the best current
> practices that network operators have in operating BGP networks in
> a 1772 replacement, we shouldn't try to reproduce works such as
> Halabi's book in a RFC.
> 

I thought Halabi's book was derived from IETF Specs and Cisco field
experience.
Thus, if RFCs are amended to include more practical things then it should
not
negate any text books that are written by any particular vendor.

> While redistributing your BGP into your IGP is a common mistake
> (and usually one that you learn from very quickly) for many network
> operators, there are valid situations where you may want to do
> this intentionally.  The real trick is to make sure that the
> redistributed routes are not accidentally re-injected back into
> BGP to prevent re-origination.
> 
> One technique that I've heard of is to simply tag the injected routes
> such that at the routers where IGP routes are injected that the
> tagged routes are excluded.  But this is just one way, and there
> is more than one way to...
>

RFC1772 Appendix A.2.2 describes this technique.

> Perhaps some suggestions from those who were about when 1772 was
> written to figure out what we should be thinking about for it.
> 
>

RFC1772 Appendix A.2.1 states that its OK to redistribute BGP routes to IGP.

I think this was written (circa 1995) before the BGP tables grew to a
significantly large size. Thus, additional recommendations placed in this 
section in the form of RFC1772bis would take care of the issue.

Ben

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 25 Sep 2002 09:58:01 -0400

I agree, both are out of scope.

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2002 8:37 AM
To: Mareline Sheldon
Cc: Misha Dovek; [email-masked]; [email-masked];
[email-masked]

Mareline,

> Misha,
> 
> > |
> > | - A discussion on multiple views/instances/processes of BGP (many ISPs
ar
e
> > | using it) and their possible interaction amongst themselves/IGPs.
> > 
> > That *might* prove interesting.
> 
> my votes on this too.

This seems to be clearly outside the scope of the *base* spec. And what we 
are discussing right now is the base spec.

> 
> > 
> > |
> > | - Limited interaction with IGPs
> > 
> > Why limited? I gathered that redistributing BGP info into IGP is a
strict N
o
> > No!
> 
> interaction with IGP does not necessarily mean redistributing routes
> to and f ro the IGPs.  There are other ways also by which BGP could
> interact with the IGPs e.g. Traffic Engineering

The interaction with IGP (including interaction with TE) is outside
the scope of the base spec. 

Yakov.

> 
> mareline s.
> 
> > 
> > |
> > | - Hierarchical peering using Route Reflectors
> > 
> > Yes, i am aware of certain ISPs doing that.
> > 
> > Misha
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 25 Sep 2002 10:06:15 -0400

I agree all are out of scope, EXCEPT id:
1) requiring id to be local addr should be removed
2) dis-allowing id to be set to martian should be added
3) allowing peers to have martian id should be added
4) RECOMENDING that id equal IGP's id should be added

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2002 8:40 AM
To: Manav Bhatia
Cc: Abarbanel, Benjamin; 'Alexei Roudnev'; 'Jeffrey Haas'; [email-masked]
Subject: Re: BGP - IGP Redistribution Issue 

Manav,

> some more things which could be pondered upon.
> 
> - Bringing down all the EBGP connections immediately when the interface
> over which they run goes down (without waiting for the HoldTimer to
> expire!).
> 
> - router id [hope am not opening a can of worms :-)]

We've been through this discussion before... 

> - A discussion on multiple views/instances/processes of BGP (many ISPs are
> using it) and their possible interaction amongst themselves/IGPs.

outside the scope of the base spec. 

> - Using communities

Ditto.

> - Limited interaction with IGPs

Ditto.

> - Hierarchical peering using Route Reflectors

Ditto (although may be well within the scope of the Route Reflectors spec).

Yakov.

P.S. Folks, the WG chairs would reallly appreciate if (at least for now)
we stay focused on discussing just the *base* spec, and defering
issues that do not belong to the base spec till some later point...

> 
> Manav
> ----- Original Message -----
> From: "Abarbanel, Benjamin" <[email-masked]>
> To: "'Alexei Roudnev'" <[email-masked]>; "Abarbanel, Benjamin"
> <[email-masked]>; "'Jeffrey Haas'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, September 24, 2002 9:53 PM
> Subject: RE: BGP - IGP Redistribution Issue
> 
> 
> | Agreed, are there other "good practice" issues that can be added to this
> | spec?
> |
> | Ben
> |
> | > -----Original Message-----
> | > From: Alexei Roudnev [mailto:[email-masked]]
> | > Sent: Tuesday, September 24, 2002 12:11 PM
> | > To: Abarbanel, Benjamin; 'Jeffrey Haas'
> | > Cc: [email-masked]
> | > Subject: Re: BGP - IGP Redistribution Issue
> | >
> | >
> | > > > As much as I would really like to incorporate some of the
> | > best current
> | > > > practices that network operators have in operating BGP networks in
> | > > > a 1772 replacement, we shouldn't try to reproduce works such as
> | > > > Halabi's book in a RFC.
> | > > >
> | > >
> | > > I thought Halabi's book was derived from IETF Specs and Cisco field
> | > > experience.
> | > It was re-written 2 years ago, without sugnificant changes.
> | >
> | > Anyway, it is a good idea to have some statement preventing
> | > people from bad
> | > practices (such as injecting bgp routes into IGP, even in
> | > small network).
> | >
> | >
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 25 Sep 2002 10:27:11 -0400

Yakov, 

This thread was created for new work on other specs. I am sorry if we are
confusing you. Is it OK to discuss these topics on the list at this time?

Regards,
Ben

> > > | - A discussion on multiple views/instances/processes of 
> BGP (many ISPs ar
> e
> > > Why limited? I gathered that redistributing BGP info into 
> IGP is a strict N
> o
> > > No!
> >

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 25 Sep 2002 10:28:30 -0400

Yakov, 

  Well do. I think these new discussions are interesting. Can you we proceed
on
some other list that you can recommend?

Ben

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 25 Sep 2002 10:29:16 -0400

Agreed, it is out of scope.  Could be in a BCP--most folks turn this feature
off, right?

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2002 10:23 AM
To: Manav Bhatia
Cc: [email-masked]
Subject: Re: BGP - IGP Redistribution Issue

> over which they run goes down (without waiting for the HoldTimer to

If your interface hiccups once due to a framing error on your
circuit that causes a flap, do you really want to bring it down?

This can be addressed out of scope from the BGP document by
having the local TCP stack be aware of sessions over a given
interface and decreasing the session timeouts when the interface
goes down.  This means you shouldn't have to wait for the full
length of time for the session to go down.

-- 
Jeff Haas 
NextHop Technologies