Subject: I-D Action: draft-kaliraj-idr-multinexthop-attribute-02.txt

From: [email-masked]
Date: Tue, 28 Dec 2021 01:26:07 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : BGP MultiNexthop attribute
        Authors         : Kaliraj Vairavakkalai
                          Minto Jeyananth
                          Gyan Mishra
	Filename        : draft-kaliraj-idr-multinexthop-attribute-02.txt
	Pages           : 21
	Date            : 2021-12-28

Abstract:
   Today, a BGP speaker can advertise one nexthop for a set of NLRIs in
   an Update.  This nexthop can be encoded in either the BGP-Nexthop
   attribute (code 3), or inside the MP_REACH attribute (code 14).

   For cases where multiple nexthops need to be advertised, BGP-Addpath
   is used.  Though Addpath allows basic ability to advertise multiple-
   nexthops, it does not allow the sender to specify desired
   relationship between the multiple nexthops being advertised e.g.,
   relative-preference, type of load-balancing.  These are local
   decisions at the receiving speaker based on local configuration and
   path-selection between the various additional-paths, which may tie-
   break on some arbitrary step like Router-Id or BGP nexthop address.

   Some scenarios with a BGP-free core may benefit from having a
   mechanism, where egress-node can signal multiple-nexthops along with
   their relationship, in one BGP route, to ingress nodes.  This
   document defines a new BGP attribute "MultiNexthop (MNH)" that can be
   used for this purpose.

   This attribute can be used for both labeled and unlabled BGP
   families.  The MNH can be used to advertise MPLS label along with
   nexthop for unlabeled families (e.g.  Inet Unicast, Inet6 Unicast).
   Such that, mechanisms at the transport layer can work uniformly on
   labeled and unlabled BGP families.  Service route scale can be
   confined closer to the service edge nodes, making the transport layer
   nodes light and nimble.  They dont have any service route state, only
   have service end-point state.

   The MNH plays different role in "downstream allocation" scenario than
   "upstream allocation" scenario.  E.g. for RFC8277 families that
   advertise downstream allocated labels, the MNH can play the "Label
   Descriptor" role, describing the forwarding semantics of the label
   being advertised.  This can be useful in network visualization and
   controller based traffic engineering (e.g.  EPE).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-kaliraj-idr-multinexthop-attribute-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts