[c-nsp] Question on BGP Link-Local peering...

[Grzegorz Banasiak]

> In trying to follow the guidance in draft-kato-bgp-ipv6-link-local-00.txt
[..]
Just out of curiosity: why are you looking at a draft which seems to have been
deleted back in 2002?

> A) BGP-4 speakers should ignore the IPv6 global address specified in the
>    next hop field in a MP_REACH_NLRI attribute learned over a link-local
>    E-BGP session, provided if it does not match with one of the IPv6
>    global prefixes assigned to the link. (It is possible to assign an
>    IPv6 global prefix to an IX and have a link-local E-BGP session.)

> C) BGP-4 implementations should be able to configure, at least per
>    session basis, which IPv6 global address is to be filled in the next
>    hop field of MP_REACH_NLRI attributes.  In the case of link-local E-
>    BGP sessions, arbitrary IPv6 address can be specified while in a
>    typical case an IPv6 global address attached to the node (other
>    interface or loopback) will be specified.

> 1) What does "BGP-4 speakers should ignore the IPv6 global address
> specified in the
>    next hop field in a MP_REACH_NLRI attribute learned over a link-local
>    E-BGP session" mean from A referenced above.  Would not the global
> address still need to be used for route propagation, rather than
> "ignored"?
The idea was obviously to get rid of global unicast addresses at IXs, so I would
guess that the answer is "no". This could work provided that BGP speakers
combined the knowledge of link-local address AND incoming interface in order to
distinguish between 2 neighbors with the same link-local addresses (neighbor
configuration would have to include that interface as well).

> 2) Stemming from above, if a loopback global address is used as
> mentioned in C above ("in a typical case an IPv6 global address
> attached to the node (other interface or loopback) will be
> specified"), how will nodes in the attached network receiving the
> advertisement know how to reach this not-attached next-hop?
Juding by A, in case of link-local peering, they would ignore such a
not-attached global address and use local one. In case of normal peerings,
changing the next-hop address to anything different than global address on a
direct link on which eBGP session is formed, should result in dropping the
prefix (unless we are talking about ebgp-multihop).

> I seem to
> be missing some magic that would allow this global address to be
> reachable and re-advertisable to iBGP peers as the upstream next-hop
> (since link-local will be useful only to the direct peer).
> - Is the global address ignores as referenced above and such peers
> must be configured to next-hop-self to their iBGP neighbors?
Yes, next-hop-self seems to be a solution.

> - Does each neighbor then need a static route installed to the global
> loopback via the link-local address?
Assuming we are talking about ebgp-multihop here:
- via interface on ptp links,
- via link-local address AND interface on broadcast links.