Subject: Re: [bess] [Idr] XXCs

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 8 Apr 2020 14:53:08 +0000

Not sure if the intention here intersects with what I had in mind in 2012.. Pradosh, Saikat and I created a draft that introduced the notion of OAD ( One Administrative Domain ). The challenge from my point of view was and still is how to treat non-transitive attributes as transitive across the set of AS domains that “belong” to the same administrative domain. An example of this is the application of Local-Pref across a set of disparate As domains that a customers VPN spans.

We are tackling a similar problem when spanning AS domains that are reflective of differing services.. i.e  a customer VPN spans EVPN and 2547 signaling domains.

https://tools.ietf.org/html/draft-uttaro-idr-oad-01

https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02

Thanks,
              Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, April 08, 2020 10:41 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: [Idr] XXCs

Hey Jakob,

So just an idea - if we are to redefine transitivity for XXC why don't we forget about all of this ASN reservations and simply instead of two transitive bits define three.

Make 3rd bit to mean transitive only under set of ASes under same administrative control ?

You still need a knob to know which ASNs are to be treated as same administration. And with that no change to community syntax  is needed at all - LOCAL_ASN:NUMBER

Done !

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 8 Apr 2020 17:07:14 +0200

Hi Jim,

Yes the topic is related to how multiple ASes under one administrative
umbrella can operate BGP.

But I must say that there are two fundamental approaches:

a) the one as you described in the OAD draft defining the ATTR_SET_STACK
attribute - sort of being an Eiffle Tower of what needs to be carried
across.

b) the other option is to decouple the problem into two sub functions:
     b.1 - make those ASNs operating under same administration aware of
each other by cfg
     b.2 - make new transitive rule to allow passing under same
administration.

I just proposed b.

Jakob proposed c) which is yet one more option to define set of reserved
values (could be ASN or a prefix for easy ACL) to indicate within given
attribute the scope of propagation when ingress policy allows. I find it
much more complex and error prone as compared with (b)

Thx,
R.

On Wed, Apr 8, 2020 at 4:53 PM UTTARO, JAMES <[email-masked]> wrote:

> *Not sure if the intention here intersects with what I had in mind in
> 2012.. Pradosh, Saikat and I created a draft that introduced the notion of
> OAD ( One Administrative Domain ). The challenge from my point of view was
> and still is how to treat non-transitive attributes as transitive across
> the set of AS domains that “belong” to the same administrative domain. An
> example of this is the application of Local-Pref across a set of disparate
> As domains that a customers VPN spans.*
>
>
>
> *We are tackling a similar problem when spanning AS domains that are
> reflective of differing services.. i.e  a customer VPN spans EVPN and 2547
> signaling domains.*
>
>
>
> *https://tools.ietf.org/html/draft-uttaro-idr-oad-01
> <https://tools.ietf.org/html/draft-uttaro-idr-oad-01> *
>
>
>
> *https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02
> <https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02> *
>
>
>
> *Thanks,*
>
> *              Jim Uttaro*
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, April 08, 2020 10:41 AM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>
> *Subject:* [Idr] XXCs
>
>
>
> Hey Jakob,
>
>
>
> So just an idea - if we are to redefine transitivity for XXC why don't we
> forget about all of this ASN reservations and simply instead of two
> transitive bits define three.
>
>
>
> You still need a knob to know which ASNs are to be treated as same
> administration. And with that no change to community syntax  is needed at
> all - LOCAL_ASN:NUMBER
>
>
>
> Done !
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>