[Idr] BGP routes with color, observations from question threads

[Jeffrey Haas <[e-mail]>]

Working Group,

Summary: For route resolution and route origination/propagation, BGP-CAR and
BGP-CT are functionally identical but operationally different.


"When I use a word," Humpty Dumpty said in rather a scornful tone, "it means
just what I choose it to mean — neither more nor less." [1]

After the most recent IDR interim meeting on 24 January, 2022 [2],
discussion during presentation and in meeting chat suggested we had need to
try to clarify some of the items in the proposals.  Two questions were sent
to the IDR mailing list to try to achieve clarity.

Question 1: How does route resolution work with your feature? [3]
Question 2: Route origination and propagation [4]

The discussion at the interim suggested that the authors weren't quite
dealing with exactly the same ideas of what a route with "color" meant from
protocol purposes, and similarly with "intent".  The threads were an attempt
to ignore the words used and to distill the BGP protocol behaviors based on
what each of the proposals did functionally.

For route resolution, both proposals permit a service route (e.g. L3VPN) to
resolve their BGP nexthops vs. multiple mechanisms using a color (typically,
the color Extended Community from RFC 9012).  Thus, each proposal not only
discussed resolution procedures vs. its mechanisms, but also vs. other
mechanism such as IGP Flex-Algo, SR Policy, BGP LU, etc.

After question 1, it's also clear that each proposal functionally provides
resolution over its routes in a similar fashion in spite of differing
descriptions of the mechanics:

- The resolution key for a service route is the BGP Nexthop, N, and the
  color on the route, C - (N,C).
- (N,C) is used in resolution by finding the longest-match destination for
  the proposal's resolution database for color C.
- Fallback resolution to different colors are permitted by each proposal to
  resolve to (N,C2), etc., via configuration.  

Both proposals have sections describing route resolution.  Both would
benefit by adding text covering the properties above to their text.

Question 1 also highlighted that the "resolution database", for wont of a
fully general term, differs in terms of how fully described it is in each of
the proposals.  This abstraction is the component where the (N,C) lookup is
performed; compare vs. RFC 4271 describing resolution in the "Routing Table".

In -CT, the "Transport RIBs" construction procedures are described.
Loosely, received -CT routes are stripped of their received RD and installed
in a longest-prefix match table (RIB) for the Transport Class extended
community that is received.  The presented abstraction is thus a set of
tables {C}.  Functionally, resolution for (C,N) is against this set of
tables but is a single operation.

In -CAR, similar detailed procedures aren't provided... nor do they
necessarily need to be described.  As long as the functional behavior for
resolution is described it doesn't matter.

By comparison, the BGP RIB model provides the following caveat in RFC 4271:

:    Although the conceptual model distinguishes between Adj-RIBs-In,
:    Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an
:    implementation must maintain three separate copies of the routing
:    information.  The choice of implementation (for example, 3 copies of
:    the information vs 1 copy with pointers) is not constrained by the
:    protocol.

I'd urge all of the authors to avoid trying to draw too much comparison to
standard BGP route resolution and instead to ensure you're calling out
explicit procedures to avoid letting people think they know what's going on
only to have issues with the gotchas:

- In -CAR, the resolution table is populated by (E,C) where C is the
  "effective color" of the -CAR route; by default C from the NLRI but
  overridden by the LCM extended community, when present.
- In -CT, while the RFC 4364-like Transport RIBs procedures and the similar
  resolution procedure is listed, the text perhaps is overly descriptive vs.
  a specific implementation.  See the RFC 4271 caveats.

-----

Question 2, while about route origination and propagation, became more of a
discussion about the perception of the authors about what they considered a
"color" and what "intent" was.  

Rather than try to argue with a given author's defintion of each of these
terms, what we can observe from the conversation are operational differences
in how "forwarding diversity" is achieved at an ingress running one of the
proposed protocols - or whether such diversity was perceived to be needed.
>From the thread: "Forwarding diversity", in this context, is situations
where forwarding properties such as BGP Nexthops, labels, SIDS, etc. are
desired to be carried through to the ingress. 

The authors illustrated in their responses that each proposal was capable of
addressing similar scenarios from a forwarding diversity standpoint.  The
authors also seem to largely agree on what scenarios are the most common.

I believe that in terms of capability for representing forwarding diversity,
both proposals are functionally identical.  However, where they differ is in
operational presentation and impact:

-CAR:

In -CAR, the NLRI (E,C) drives the scenario to use C for a specific desired
forwarding "intent".  That intent is not intended to address "forwarding
diversity".  If there is a desire for such diversity for a given endpoint,
an additional color must be leveraged.

Since the color is part of the NLRI key, this has the operational impact
that multiple "color domains" MUST agree on a common color space for the
intent for a specific C.  Domains are capable of mapping between each
others' intents using LCM, but C must not be inconsistently used among
cooperating domains.  However, by having the color in the NLRI and given the
need for coordination of the color space, the original "intent" of the route
is carried from originator to consumer.

If fowarding diversity is desired for the same endpoint, multiple colors
might need to be used depending on topology.  Based on author discussion,
such diversity is not the expected common scenario.


-CT:

The Route Distinguisher in -CT has the same properties as in most BGP VPN
technologies; i.e. it is primarily to provide path uniqueness.
Operationally, the authors seem to foresee that it is primarily meant to be
used to provide information as to what the originating PE is for the routes.

In situations where path uniqueness is not required, the operator may
configure identical RDs for a given endpoint.

A common scenario for -CAR and -CT is the endpoint PE originating the route.
In such situations, diverse RDs may not be needed.

Since the NLRI doesn't contain the color and it is solely an extended
community (similar to LCM), the original "intent" of the color is not
necessarily carried across different color domains.  

Forwarding diversity is available for the same "color" by varying the RD.

For more direct comparability for forwarding diversity, one might consider
RD+color in -CT to be the same as color in -CAR.

Personal observation: RDs have enough space such that a 32-bit color could
be encoded in it to preserve the "original intent".

---

In the above, I believe we can see that both proposals are capable of
encoding similar desired forwarding diversity.  Where the proposals seem to
diverge is whether forwarding diversity is intended to directly map to their
32-bit color component.

Hopefully the above can serve to help the SPRING Working Group with their
discussion on the problem statement work behind these proposals.  While
each of the authors likely has a precise meaning for "color" and "intent" in
mind, the above tries to be mostly mindful of what the functional properties
are present in their BGP proposals.

A portion of the issue we're dealing with is that the word "color" has been
heavily used in IETF RFCs and Internet-Drafts over the years without
ensuring consistency of its meaning.  An example of this is how color in an
RSVP admin-group sense is not comparable to the RFC 9012 BGP extended
community sense.  Harmonizing the functional behaviors of "color" may be
possible in a set of proposals, but I suspect that when dealing with legacy
technologies it can't be readily done.
 

-- Jeff

[1] https://www.goodreads.com/quotes/12608-when-i-use-a-word-humpty-dumpty-said-in-rather
[2] https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr
[3] https://mailarchive.ietf.org/arch/msg/idr/OaNnE5epcaK7GtcV8OlAVdD3ZbI/
[4] https://mailarchive.ietf.org/arch/msg/idr/4MYIFyHWITj8-Kk38AmKlkhh5b8/