[Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

[Jeffrey Haas <[e-mail]>]

WKLC authors,

Let me use Brian's text here as a starting point to raise issues about
interpreting WKLC with regard to their transitivity bits.  I don't believe
the issue here is irreconcilable, but it does play to a point Brian was
illustrating and that it somewhat dilutes the deployed feeature argument.

On Fri, Mar 12, 2021 at 10:13:31AM -0800, Brian Dickson wrote:
> However, the router implementations, for the most part, permit filtering of
> LCs on the basis of 3 32-bit values, where either literal values or
> wildcards can be used.
> Having the elements be aligned on the 32-bit boundary, and having TBD1 and
> TBD2 be fixed values, permits LC matching using a patterns of either
> TBD1:TBD2:* (wild-card), or TBD1:TBD2:ASN (explicit ASN match).
> In other words, this structure choice is forced by router implementations,
> and really not appropriate to second-guess. It isn't up for negotiation, as
> this is a necessary requirement for the first use case.

For reference, the layout of a WKLC from the draft is:

:       0                   1                   2                   3
:       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |1 1 1 1 0 1| T |    WKLC ID    |          Data 1               |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |                             Data 2                            |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |                             Data 3                            |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A property that extended communities had as a result of how the authors
designed the feature, and later firmed up by Eric Rosen as part of registry
work was that a given extended community did NOT have a guarantee of the
same semantics when you had a transitive vs. a non-transitive version.

If it did, using link-bandwidth as an example, one's code would treat the
transitivity bit as a "don't care" for purposes of comparison.  I'm not
aware of any implementation that does this.[1]

The behavior of the transitivity bits for WKLC isn't directly discussed in
the document in terms of whether they have "don't care" semantics or not.

WKLC in particular discusses changing transitivity flags:

:         3 - One-time Transitive: The WKLC is transitive across ASes
:             under the same administration and into an AS under the
:             neighboring administration, but not into an AS under a
:             further administration.  A BGP speaker that receives a WKLC
:             with transitivity 3 on an external BGP session on an
:             administrative boundary SHOULD change the transitivity to 2.

The implication here leans toward this meaning they're "don't care", but
that may be my interpretation.

This primarily is an issue for "singleton" communities, like link-bandwidth.
While that may not be the target for the first use cases of the draft, it
should be part of the considerations for the feature's definition.

Related nit: Define your transitivity behavior for BGP confederations.

-- Jeff

[1] In the early 2000's when the extended community feature was being
disussed in IDR and I was a junior BGP dev, I did try to push the authors
toward treating transitivity as a don't care, and the sub-type field as a
"format field" for generic parsing.  Clearly my opinion didn't win out.
This results in extended community parsing being a snake's nest of special
cases with some generic patterns in use.