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]>]

Any transitivity can be done with route-policy.

What started me thinking about transitivity was a few things.
1. Operators don't like totally transitive communities,
   because they will spread far, where they're not wanted.
   We had to implement a feature many years ago that
   blocked all communities by default at AS boundaries.
2. Link bandwidth extended community is non-transitive,
   but useful across a single AS boundary.
   We had to implement a feature to send it across the AS
   boundary where it was originated.
3. Some operators have several ASes.

Sriram's draft ideally needs 2 AS hop transitive.
It needs it by default, because if vendors block
it by default, it will never work.

I got 2 bits for transitivity and don't want to burn another bit
for it. So I'm thinking of replacing administration transitive with
2 AS hop transitive.

About bright sparks using ASNs they're not supposed to:
That's their mistake and will be their failure.
We cannot stop people attaching incorrect communities to routes.
We cannot let the possibility of bright sparks doing dumb things
impede progress.

Regards,
Jakob.

-----Original Message-----
From: Ben Maddison <benm=[e-mail]> 
Sent: Saturday, March 20, 2021 12:55 AM
To: Jakob Heitz (jheitz) <[e-mail]>
Cc: Gyan Mishra <[e-mail]>; [e-mail]
Subject: Re: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

Hi Jakob,

On 03/20, Jakob Heitz (jheitz) wrote:
> A local configuration is required to make an eBGP session NOT
> an administration boundary. This configuration should be
> applied at both the sender and at the receiver.
> Without configuration, every eBGP session is also treated
> as an administration boundary.
> 
I fear this may end up being a bit too binary.
Depending on the semantics that end up in WKLCs, a pair of operators may
need to treat a session as a boundary with respect to WKLC-A, but not
with respect to WKLC-B.
Without knowing exactly what semantics may be defined in the future,
it's rather hard to know whether this will be important or not.

> An iBGP session is no boundary.
> 
CE-PE via iBGP in an IP-VPN?
This probably needs to be a configurable default too.

> The transitivity bits should not be used for LC matching if the LC begins
> with the WLC distinguisher bits 111101.
> Such LCs should not exist in the public internet, because ASNs beginning
> with those bits have not been assigned.
> 
Has the assumption that these don't exist in the wild wild DFZ been
checked?

One of the motivations for the shape of LCs was to give operators an
alternative to defining semantics in private/unallocated ASN namespaces,
so these *shouldn't* have appeared.
But I wouldn't put money on the fact that some bright spark hasn't gone
and polluted this range already.

Cheers,

Ben