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

["Jakob Heitz (jheitz)" <[e-mail]>]

Jeff,

I'm glad you brought that up.
IMO, it's "don't care".

It matters in duplicate detection.
If the LC attribute contains a particular WKLC and the same WKLC
were to be added, say by a route-policy statement, but with a
different transitivity, do you add both of them or just one of
them and if so, which one do you keep?

I'm just going to stick my neck out and say:
keep the value with the longest transitivity.
So, in the draft, the highest numerical transitivity.

The reasoning:
Suppose you keep both. What is the behavior?
Assume that the decision taken by a BGP speaker at a WKLC match
does not depend on the transitivity, but only on the other bits.
If two identical community values exist in a community attribute,
then the decision is exactly the same as if there were only one.
Therefore discarding the value with the shorter transitivity
does not change routing behavior.

The transitivity should matter only in the decision to propagate
and no other decision. If that's a good assumption, then it should work.

I just made this up on the spot, so I might have missed something.
Shoot.

Regards,
Jakob.

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Jeffrey Haas
Sent: Friday, March 19, 2021 9:30 AM
To: [e-mail]
Subject: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

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.

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr