[Idr] Re: I-D Action: draft-ietf-idr-linklocal-capability-01.txt

[Jeffrey Haas <[e-mail]>]

Working Group,

In the interest of transparency, significant numbers of edits driven by issues raised during adoption were addressed in github review for this version of the draft.  These are tracked here:
https://github.com/ietf-wg-idr/draft-ietf-idr-linklocal-capability/issues <https://github.com/ietf-wg-idr/draft-ietf-idr-linklocal-capability/issues>

You're encouraged to review the new version of the draft and consider whether prior resolved issues raised by list discussion are adequatedly addressed in this version.

The primary procedural issue that remains in the draft from the original set of comments has to deal with link local nexthops (LLNH) and route redistribution.  In particular, procedures for iBGP, route reflectors, and perhaps even under some edge cases route servers.

LLNHs are scoped to a single interface.  iBGP procedures from RFC 4271 and also RFC 4456 suggests we redistribute routes without changing the nexthop and permit route resolution to do our work for us.  However, since LLNHs are interface scoped, this can only be done in the context of redistributing a route from a peer on one interface to another peer on the same interface.

Any redistribution of a LLNH from one interface to another interface will require changing the nexthop.

For eBGP speakers, such changes to the nexthop are expected.  For iBGP, it's not currently what we expect.  However, it becomes a requirement.

The discussion point this cues for the working group: What should the procedure be and how should it be documented?

One possible way to handle this is this simply becomes a "next hop self" operation.  This places the router redistributing such routes into the forwarding path.  

The format of such a nexthop would depend on how it is redistributed. For example, if redistributed to another LLNH-only session to a peer that is one hop away, another LLNH-only can be used.  But similarly, standard RFC 2545 procedures may be used where a global and potentially a LLNH is attached.



-- Jeff

> On May 30, 2025, at 1:43 PM, [e-mail] wrote:
> 
> Internet-Draft draft-ietf-idr-linklocal-capability-01.txt is now available. It
> is a work item of the Inter-Domain Routing (IDR) WG of the IETF.
> 
>   Title:   Link-Local Next Hop Capability for BGP
>   Authors: Russ White
>            Jeff Tantsura
>            Donatas Abraitis
>   Name:    draft-ietf-idr-linklocal-capability-01.txt
>   Pages:   10
>   Dates:   2025-05-30
> 
> Abstract:
> 
>   BGP [RFC4271], was originally designed to provide reachability
>   between domains and between the edges of a domain.
> 
>   To support IPv6 reachability, BGP relies heavily on its Multiprotocol
>   Extensions as defined in [RFC2545], which is crucial for enabling
>   BGP-4 to advertise IPv6 routes alongside IPv4.  This extension not
>   only permits the exchange of IPv6 routing information but also
>   establishes the structure for IPv6 next hop handling within BGP
>   updates.  As such, BGP assumes the next hop towards any reachable
>   destination may not reside on the advertising speaker, but rather may
>   either be through a router connected to the same subnet as the
>   speaker, or through a router only reachable by traversing multiple
>   hops through the network.  [RFC2545] introduced the ability to
>   advertise a global IPv6 address as the BGP next hop.  When the
>   advertising system is directly attached, it may include both a global
>   and an IPv6 link-local address or only a global address, when next
>   hop length is set to 16 bytes.
> 
>   This document updates the specification to clarify the encoding of
>   the BGP next hop when the advertising system is directly attached and
>   only an IPv6 link-local address is available.
> 
>   This clarification applies specifically to IPv6 link-local addresses
>   and does not pertain to IPv4 link-local addresses as defined in
>   [RFC3927].
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-linklocal-capability/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-idr-linklocal-capability-01.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-linklocal-capability-01
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]