Subject: RE: Generial Editorial Comment

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

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Monday, September 23, 2002 1:00 PM
> To: Abarbanel, Benjamin
> Cc: 'Manav Bhatia'; [email-masked]
> Subject: Re: Generial Editorial Comment 
> 
> 
> Ben,
> 
> > > Ben,
> > > 
> > > > IBGP by itself in most text implies the internal BGP 
> > > protocol, same applies
> > > > to EBGP. Therefore adding the word peer to it completes 
> the intended
> > > > meaning.
> > > > 
> > > > on p. 4 "taking care not to lose BGP attributes that will 
> > > be needed by EBGP
> > > >          speakers ..."
> > > > 
> > > > on p. 4 "Care must be taken to ensure that the interior routers
> > > >          have all been updated with transit information 
> > > before the EBGP
> > > >          speakers announce ..."
> > > > 
> > > > on p. 4 "... BGP speakers within the AS maintain direct 
> > > IBGP connections
> > > > ..."
> > > > 
> > > > on p. 4 "... it is assumed that BGP information is passed 
> > > within an AS
> > > >          using IBGP." 
> > > 
> > > Here is the replacement text:
> > > 
> > >            A consistent view of the routes exterior to 
> the AS can be
> > >    provided by having all BGP speakers within the AS 
> maintain direct 
> > >    IBGP with each other. Alternately the IGP can pass BGP 
> information
> > >    among routers within an AS, taking care not to lose 
> BGP attributes 
> > >    that will be needed by BGP speakers for advertisements 
> to external
> > >    peers if transit connectivity is being provided. For 
> the purpose
> > >    of this document, it is assumed that BGP information is passed
> > >    within an AS using IBGP. 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.
> > >
> > 
> > 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.

Ben

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 Sep 2002 10:09:34 -0700

Ben,

[clipped...]

> outside the scope of this document. Via previous discussion on this list.

That is correct. And with this in mind, let's just delete the sentence.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 Sep 2002 10:27:28 -0700

Ben,

[clipped...]

> 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.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 23 Sep 2002 13:56:51 -0400

Yakov,

> Just to add to my previous e-mail, here is the modified paragraph:
[...]

>    IBGP with each other.

"direct IBGP" slightly implies that the routers are directly connected
to each other - i.e. on the same link.

I'd suggest "maintain IBGP connections/sessions"

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 Sep 2002 11:04:30 -0700

Jeff,

> I'd suggest "maintain IBGP connections/sessions"

The term "IBGP" means "BGP connection between internal peers".
So, there is no need to say "IBGP connections" - "IBGP" should be
sufficient. I'll be glad to drop the word "direct" though...

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 23 Sep 2002 14:10:26 -0400

Yakov,

> sufficient. I'll be glad to drop the word "direct" though...

That would work.

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 23 Sep 2002 22:05:53 -0400

In message <[email-masked]>, Yakov Rekhter writes
>    service is being provided.

That's fine too.  Sorry for not reading to the end of the thread
before replying.

Curtis