Re: diffs to draft-ietf-idr-bgp4-03.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Yakov Rekhter writes:
> Curtis,
> 
> >      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 interior routing protocol.  A
> >      consistent view of the routes exterior to the AS can be provided by
> > !    having all BGP speakers within the AS maintain direct IBGP connections
> > !    with each other.  Alternately the interior routing protocol can
> > !    pass BGP information among routers within an AS, taking care not to
> > !    lose BGP attributes that will be needed by EBGP speakers if transit
> > !    connectivity is being providided.  For the purpose of discussion,
> > !    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 EBGP speakers
> > !    announce to other ASs that transit service is being provided.
> 
> Despite the fact that the notion of using IGP to carry BGP information
> within an AS isn't new, and had been discussed within the IDR WG on
> more than one occassion, we've yet to see any progress in this area.
> So, why should the BGP spec describe something that doesn't exist ?
> 
> Yakov.


Because "Alternately the interior routing protocol can [in principle]
pass BGP information among routers within an AS, taking care not to
lose BGP attributes".

BGP info *is* carried by IGPs and it *does* lose information.  That is
why we have to mention how it would be done right in order to point
out where it is being done wrong.

IMO Doing BGP injection with full attributes into a flooding IGP is a
better design that IBGP, whether you use reflectors, or BGP
communities, or whatever.  For some OSPF implementations it is a very
bad idea but that is a weakness of a specific implementation.
Regardless of whether it is better it is a valid design and this
statement is needed to distinguish between that vaild design and
injection into an IGP and losing the AS path.

Curtis


ps-  Geez - you want to leave deaggregation in and drop this?  :-)