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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, "David J. LeRoy" writes:
> 
> Also, while we are trying to clear up the wording about IBGP and EBGP, I
> believe it should be used consistantly and so "external peers" should
> replace
> all occurences of "BGP speakers in neighboring autonomous systems"

YES!!  :-)

> ***************
> *** 1385,1397 ****
>      as a NEXT_HOP, for a route that the speaker is originating.  A BGP
>      speaker must never install a route with itself as the next hop.
>   
> !    When a BGP speaker advertises the route to a BGP speaker located in
> !    its own autonomous system, the advertising speaker shall not modify
> !    the NEXT_HOP attribute associated with the route.  When a BGP speaker
> !    receives the route via an internal link, it may forward packets to
> !    the NEXT_HOP address if the address contained in the attribute is on
> !    a common subnet with the local and remote BGP speakers.
> ! 
>   
>   5.1.4   MULTI_EXIT_DISC
>   
> --- 1385,1399 ----
>      as a NEXT_HOP, for a route that the speaker is originating.  A BGP
>      speaker must never install a route with itself as the next hop.
>   
> !    When a BGP speaker advertises a route to internal peers received
> !    via an external link, the advertising internal speaker shall not
> !    modify the NEXT_HOP attribute associated with the route. When a BGP
> !    speaker receives the route via an internal link, it may directly
> !    forward packets to the NEXT_HOP address if the peer shares a common
> !    subnet with the address contained in the NEXT_HOP attribute. If the
> !    address is not on a common subnet, the receiving internal peer must
> !    consult its IGP routing table for a viable nexthop towards the
> !    address contained in the NEXT_HOP attribute. 
>   
>   5.1.4   MULTI_EXIT_DISC


This is an improvement.

The first paragraph is still a jumble (I see Dave wasn't brave enough
to try to unscramble that one :).

First of all, the paragraph described third party next hop, but
doesn't describe first party next hop.  The text below assumes the
introductory text defining IBGP, EBGP, IBGP peer, and EBGP peer is
accepted.  See if this one is an improvement.

Curtis


***************
*** 1292,1311 ****
  
     The NEXT_HOP path attribute defines the IP address of the border
     router that should be used as the next hop to the destinations listed
!    in the UPDATE message.  If a border router belongs to the same AS as
!    its peer, then the peer is an internal border router. Otherwise, it
!    is an external border router.  A BGP speaker can advertise any
!    internal border router as the next hop provided that the interface
!    associated with the IP address of this border router (as specified in
!    the NEXT_HOP path attribute) shares a common subnet with both the
!    local and remote BGP speakers. A BGP speaker can advertise any
!    external border router as the next hop, provided that the IP address
!    of this border router was learned from one of the BGP speaker's
!    peers, and the interface associated with the IP address of this
!    border router (as specified in the NEXT_HOP path attribute) shares a
!    common subnet with the local and remote BGP speakers.  A BGP speaker
!    needs to be able to support disabling advertisement of external
!    border routers.
  
     A BGP speaker must never advertise an address of a peer to that peer
  
--- 1354,1378 ----
  
     The NEXT_HOP path attribute defines the IP address of the border
     router that should be used as the next hop to the destinations listed
!    in the UPDATE message.  When advertising a NEXT_HOP attribute to an
!    EBGP peer, a router may use one of its own interface addresses in the
!    NEXT_HOP attribute provided the EBGP peer to which the route is being
!    advertised shares a common subnet with the NEXT_HOP address.  This is
!    known as a "first party" NEXT_HOP attribute.  An EBGP speaker can
!    advertise an interface of any IBGP peer router in the NEXT_HOP
!    attribute provided the EBGP peer to which the route is being
!    advertised shares a common subnet with the NEXT_HOP address.  This is
!    known as a "third party" NEXT_HOP attribute.  An EBGP speaker can
!    advertise any EBGP peer router in the NEXT_HOP attribute provided that
!    the IP address of this border router was learned from an EBGP peer and
!    the EBGP peer to which the route is being advertised shares a common
!    subnet with the NEXT_HOP address.  This is a second form of "third
!    party" NEXT_HOP attribute.
! 
!    Normally the NEXT_HOP attribute is choosen such that the shortest
!    available path will be taken.  A BGP speaker must be able to
!    support disabling advertisement of third party NEXT_HOP attributes
!    to handle imperfectly bridged media.
  
     A BGP speaker must never advertise an address of a peer to that peer