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

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.

An iBGP session is no boundary.

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.

Regards,
Jakob.

From: Gyan Mishra <[e-mail]>
Sent: Friday, March 19, 2021 4:57 PM
To: Jakob Heitz (jheitz) <[e-mail]>
Cc: Jeffrey Haas <[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 Jacob

In their local configuration as to administrative boundary versus not an administrative boundary?

Or is it that any eBGP session is administrative boundary and every iBGP session is a non administrative boundary?

With regards to transitive versus non transitive in the path selection if their is a match on WKLC or duplicate with existing LC deployed, the higher less transitive bit is always preferred correct?





        0 - Transitive: The WKLC is transitive across ASes.



        1 - Non-transitive: The WKLC is not transitive across ASes.



        2 - Administration Transitive: The WKLC is transitive across

            ASes under the same administration only.  By default, every

            AS boundary is also an administration boundary.  If an

            external BGP session is configured as a non-administrative

            boundary, then it will send and receive WKLCs with

            transitivity 2, else it will discard the WKLC from the

            UPDATE message.



        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.



Thanks

Gyan


On Fri, Mar 19, 2021 at 5:23 PM Jakob Heitz (jheitz) <jheitz=[e-mail]<mailto:[e-mail]>> wrote:
Yes.

Regards,
Jakob.

-----Original Message-----
From: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Sent: Friday, March 19, 2021 2:44 PM
To: Jakob Heitz (jheitz) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

Jakob,

On Fri, Mar 19, 2021 at 08:40:15PM +0000, Jakob Heitz (jheitz) wrote:
> 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.

I understand your thinking here.  A few related observations:

Since large communities will exist prior to this feature being added, policy
may occur on some implementation without WKLC that adds communities that
could be duplicate.  This means we already need to be ready to deal with
handling duplicates.

Your policy now has to deal with being able to alter scope.  E.g.:
if match wklc-foo:
         set wklc-transitivity non-transitive;


-- Jeff

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347