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=
40cisco.com@dmarc.ietf.org> wrote:

> Yes.
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>
> Sent: Friday, March 19, 2021 2:44 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: idr@ietf.org
> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*