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

["David J. LeRoy" <[e-mail]>]

In regards to the editorial comments, one inconsistency which should be 
clarified is that the NextHop attribute used to be a manditory attribute
but is listed in the edits as discretionary and references are made in
the route selection text to that effect ("if NEXT_HOP is not provided")


>         c)   NEXT_HOP (Type Code 3):
>
>            This is a well-known mandatory attribute that defines the IP
>            address of the border router that should be used as the next
>            hop to the destinations listed in the Network Layer
>            Reachability field of the UPDATE message.


>      attribute           EBGP                    IBGP
>       ORIGIN             manditory               manditory
>       AS_PATH            manditory               manditory
>       NEXT_HOP           discresionary           discresionary
>       MULTI_EXIT_DISC    discresionary           discresionary
>       LOCAL_PREF         disallowed              required
>       ATOMIC_AGGREGATE   discresionary           discresionary
>       AGGREGATOR         discresionary           discresionary


>      1.  NEXT_HOP.  The next hop must be reachable, or if NEXT_HOP is
>           not provided, the advertising router must be reachable)


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"

Less of a nit, I'd like to see the wording in section 5.1.3 made
clearer. I
took a shot at the last paragraph, but am uncertain of the intent of the
text
in the 1st paragraph (especially dealing with internal border routers)
Is this
describing the behavior of IBGP speakers originating routes to internal
peers,
because the last paragraph is explicitely saying not to modify the
NEXT_HOP
received from internal peers? Below is the edit for the last paragraph
of 5.1.3

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


Dave