IETF Logo Mail Archive

Re: [Idr] XXCs

"UTTARO, JAMES" <ju1738@att.com> Wed, 08 April 2020 14:53 UTC

Return-Path: <ju1738@att.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FA33A0E09; Wed, 8 Apr 2020 07:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_6ni8IDNmF6; Wed, 8 Apr 2020 07:53:29 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CC83A0EB9; Wed, 8 Apr 2020 07:53:20 -0700 (PDT)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 038EqIgE028917; Wed, 8 Apr 2020 10:53:19 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 3091nx4w1v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Apr 2020 10:53:19 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038ErF9h007091; Wed, 8 Apr 2020 10:53:18 -0400
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 038Er9Bg006912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2020 10:53:09 -0400
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 7D9B94009E92; Wed, 8 Apr 2020 14:53:09 +0000 (GMT)
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30487.vci.att.com (Service) with ESMTPS id 66D6040002AB; Wed, 8 Apr 2020 14:53:09 +0000 (GMT)
Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) by GAALPA1MSGHUBAF.ITServices.sbc.com (130.8.218.155) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 8 Apr 2020 10:53:08 -0400
Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Apr 2020 10:53:08 -0400
Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.1913.007; Wed, 8 Apr 2020 10:53:08 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: Robert Raszuk <robert@raszuk.net>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>
CC: "idr@ietf. org" <idr@ietf.org>, BESS <bess@ietf.org>
Thread-Topic: [Idr] XXCs
Thread-Index: AQHWDbPmin7NOrnJA0mevIT3SnuJCahvTTiA
Date: Wed, 08 Apr 2020 14:53:08 +0000
Message-ID: <1ab5b013e630448583d2e55179fa5c8c@att.com>
References: <CAOj+MMEhJtfa+CjVgMT-eV=LbwTPxcmkT2zstFQB-GygHDWpug@mail.gmail.com>
In-Reply-To: <CAOj+MMEhJtfa+CjVgMT-eV=LbwTPxcmkT2zstFQB-GygHDWpug@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.132.73]
Content-Type: multipart/alternative; boundary="_000_1ab5b013e630448583d2e55179fa5c8cattcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-07_10:2020-04-07, 2020-04-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 suspectscore=0 spamscore=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 mlxlogscore=875 adultscore=0 bulkscore=0 clxscore=1011 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004080122
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/A9sov_KimH8G-2oT-2Azln7YIz8>
Subject: Re: [Idr] XXCs
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 14:53:40 -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 <idr-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Wednesday, April 08, 2020 10:41 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: idr@ietf. org <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.

v2.23.0 | Report a Bug | By Email