Re: [bess] [Idr] XXCs

[Robert Raszuk]

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  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-ietf-bess-evpn-ipvpn-interworking-02
>  *
>
>
>
> *Thanks,*
>
> *  Jim Uttaro*
>
>
>
> *From:* Idr  *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, April 08, 2020 10:41 AM
> *To:* Jakob Heitz (jheitz) 
> *Cc:* idr@ietf. org 
> *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.
>
>
>
>
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] XXCs

[UTTARO, JAMES]

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  On Behalf Of Robert Raszuk
Sent: Wednesday, April 08, 2020 10:41 AM
To: Jakob Heitz (jheitz) 
Cc: idr@ietf. org 
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.




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess