Subject: RE: Generial Editorial Comment

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 23 Sep 2002 10:45:52 -0400

Correct.  

LOL,
Ben

> -----Original Message-----
> From: Mareline Sheldon [mailto:[email-masked]]
> Sent: Monday, September 23, 2002 10:41 AM
> To: Manav Bhatia; Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: Re: Generial Editorial Comment
> 
> 
> Manay,
> I guess what Ben wanted to state was that an IBGP peer makes 
> more sense than an internal peer
> and the same for EBGP peer.
> 
> mareline s.
> 
> --- Manav Bhatia <[email-masked]> wrote:
> > Ben,
> > 
> > | > IBGP stands for "BGP connection between internal 
> peers". Therefore
> > | > the term "IBGP Peer" would mean "BGP connection between internal
> > | > peers peer".  That doesn't seem appropriate.
> > | >
> > | If you are a BGP AS border router, you have an (internal) 
> IBGP peer and
> > an
> > | (external) EBGP peer. Where is the confusion?
> > 
> > Refer to Section 3 - Summary of operations which clearly 
> states that " .. a
> > peer in a different AS is referred to as an external peer, 
> while a peer in
> > the same AS may be described as an internal peer. Internal 
> BGP and external
> > BGP are commonly abbreviated IBGP and EBGP"
> > 
> > Regards,
> > Manav
> > 
> > 
> > 
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 23 Sep 2002 13:47:58 -0400

Yakov,

Excellent, lets go with this version.

Thanks,
Ben

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Monday, September 23, 2002 1:27 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> [clipped...]
> > > > Overall paragraph sounds good to me.
> > > > 
> > > > Except one sentence does'nt sound right.
> > > > 
> > > > "Alternately the IGP can pass BGP information among routers 
> > > within an AS,
> > > >  taking care not to lose BGP attributes". 
> > > > 
> > > >  Is it possible for IGP protocols (OSPF/ISIS) to carry such 
> > > BGP attributes
> > > > as  "AS PATH", in their link state packets?
> > > 
> > > It is certainly possible, at least in *theory*, to define new 
> > > TLVs to carry
> > > BGP attributes in OSPF/ISIS. Whether doing this makes sense 
> > > in *practice*
> > > is a separate issue. I think it would be fair to say that 
> we've yet to
> > > see any empirical evidences that doing this would be any 
> > > better than using 
> > > IBGP. And it is certainly true that as of today neither 
> ISIS nor OSPF
> > > supports this capability.
> > > 
> > > So, with this in mind I think we should either (a) delete 
> > > this sentence
> > > altogether, or (b) replace it with the following:
> > > 
> > >   Alternately, at least in principle, the IGP (with appropriate
> > >   extensions) can pass BGP information among routers within an AS,
> > >   taking care not to lose BGP attributes. At the time of 
> this writing
> > >   none of the IGPs have this capability. Whether doing this would
> > >   offer any practical benefits over using IBGP is outside 
> the scope
> > >   of this document.
> > > 
> > > Yakov.
> > > 
> > 
> > I thought inter-working with other protocols such as IGP 
> (OSPF/ISIS) is
> > outside the scope of this document. Via previous discussion 
> on this list.
> 
> Just to add to my previous e-mail, here is the modified paragraph:
> 
>    If a particular AS has multiple BGP speakers and is providing
>    transit service for other ASs, then care must be taken to ensure
>    a consistent view of routing within the AS. A consistent view
>    of the interior routes of the AS is provided by the IGP used
>    within the AS. For the purpose of this document, it is assumed
>    that a consistent view of the routes exterior to the AS is
>    provided by having all BGP speakers within the AS maintain direct
>    IBGP with each other. Care must be taken to ensure that the
>    interior routers have all been updated with transit information
>    before the BGP speakers announce to other ASs that transit
>    service is being provided.
> 
> Yakov.
>