Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-open-policy-18

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Tue, 04 January 2022 16:36 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398763A1E17; Tue, 4 Jan 2022 08:36:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.027
X-Spam-Level:
X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.351, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 Xi4fWYw0-EPD; Tue, 4 Jan 2022 08:36:00 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::72b]) (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 490563A1E19; Tue, 4 Jan 2022 08:36:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=momJLFOnmqt3XyWq78Lmlwac6Kft2WiRJE/N1AIc43yUGp9Ni5lCwMJMaDB0HWw9SQyzdSlOWY0TL6uf38vyyh2BE6Au+wFxo6AoTqpaDyN9Q37++1o4olrfcBXxgErB9R5MlMrqic8XTf3J1dwJtaZOny2/IhyodW4InHbGI+DFc9oZzvBrPDveMsOYwhBcqKCw8c1SgWCL/TVh7e4jouEYfrFnbsoAFLAqqfBSJcAIqPl2ziXxy4dnPdr8iZgnjwvwma16mHVL7MdCHmCdWzr1qaEg1MlJ6qJNgOMF3lMlTzpbXZphhMYgIPlHqUmE0CynSTa1jRNTgHmS3gxtQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=N/NeUrDdbIwNcMRJctuTyBLbDfGP9f0ie4JDdJ4rVWo=; b=a33St5eREZG6Bwrf0mZ0ELiwLOhdqmkU5OXLfIi6uxksfpKrZKmD9u2gaXN35bf0+91LYaYArZQYB8fYi5GmW1JO4zc8b6Bsd4lTGe5W13NLUFQLa7Aa7mcx2kXat0k3MyHwRERtIF/WP5AVjfTkUymzeK+GZadHSBe0GrKaPdTFtky1nanBiig0Uh6+D9rs/c7Kc7s+TTTm/EOZihGxGsSM54qn7AzjPqLTTlZnkNqqmTxUUi4U8PwCJZHC6WO1z/N4ZbbK3ucTV0yDhnHQNcqnEifdTmJqK6fbhmN1bowwjPQpkce29vdwId27BQNfH+ZUzW4Slybob4+FRRucTw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N/NeUrDdbIwNcMRJctuTyBLbDfGP9f0ie4JDdJ4rVWo=; b=O8W1fsxArswe8ceWbBbWc0alcYHqMqpTQ72ruCiGFzlEtNVEQDHTjysYoreE7M2wsv3J5VqoYZ5/l0iSL7+JkKcyuGJDwKggUMZuI/AT+bjs1hRt4QAfpGD3iTAAC4csAZnlep81tqdAxPe+CiSm2RvwTWbOYzaF2/4mDye7TOM=
Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB8606.namprd09.prod.outlook.com (2603:10b6:806:174::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.14; Tue, 4 Jan 2022 16:35:51 +0000
Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::717a:2702:70fb:6225]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::717a:2702:70fb:6225%4]) with mapi id 15.20.4844.016; Tue, 4 Jan 2022 16:35:51 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Gyan Mishra <hayabusagsm@gmail.com>, Alvaro Retana <aretana.ietf@gmail.com>
CC: "draft-ietf-idr-bgp-open-policy.all@ietf.org" <draft-ietf-idr-bgp-open-policy.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-idr-bgp-open-policy-18
Thread-Index: AQHX9s+XH9Ok71AVyEOJ/vho1li1GaxTDVkAgAAI7QCAAAEmYA==
Date: Tue, 04 Jan 2022 16:35:50 +0000
Message-ID: <SA1PR09MB8142D79278F793814694AD40844A9@SA1PR09MB8142.namprd09.prod.outlook.com>
References: <164013488006.27197.13873644386825552452@ietfa.amsl.com> <CAMMESsx35+gC7CP9ox+U-QsT8Dxkv3=Du8VRq_cprMsEc5PCyQ@mail.gmail.com> <CABNhwV30nrqJ-mOpniso6c=rJpFi0zQX93BWaQKJvKNVcrMNAw@mail.gmail.com>
In-Reply-To: <CABNhwV30nrqJ-mOpniso6c=rJpFi0zQX93BWaQKJvKNVcrMNAw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 704c1ec8-d899-4ccb-404a-08d9cfa04530
x-ms-traffictypediagnostic: SA1PR09MB8606:EE_
x-microsoft-antispam-prvs: <SA1PR09MB8606B20648C77A0CA00ED596844A9@SA1PR09MB8606.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: coibYsbxLDSh2KiG8Cy9hYpUmQRBDfugLYDGtDrVzBIj9qUtDW5DvQ/YAPqUC+W2DiP2JyQWJ60bFkAX3rSj0uhwX83fxWtUQAGse50O9HTtNhx1IJboyPMDQm973eZgRkOcSFBHL8c0A3HwMIbdqvwaJvV5dE4R29JVvStdLCDYMav90qYsVIw8skMbFsmB8j9Z0yM2/t1CAHpg0EKI7KRIB0rpo5Olp2KCiHTSVX1j0Hlp3P6Ao1jNLpMZVyzkjqrmrmnaNpYXEcptnKr6Gsx+owB8l7M2pvgmWbAKg2q0F1LP4SWaJjDFtq7OVKu4aaCiEkHSeTv0x3YrlpX22TjlS6ptfT5udHKocldkSvA25Vlk63Vsy7nzE5QKKlnvsJWvlRQfE2RiybmQq4yvG5OycsAtutaWI3nuyrFRhO4PVFSSxe0kCgzlWIx/6zcK5uk0jRaVRpQ9NvKpVXMtvYogqFkeV5pq0b9NypQuMnNJlBsgO4TZY2VGMu5viAuZssI+Ud2fhjFW6KU+ymfKlc9Adf952Rv4Uag6rZTZZM7vKJZRg7JZami48phY4EzistRLMfnchrpJWK2XdcrPxyFH8jvkmNacXRCLajM5w3HtbTD0p7ZFU7qGRjN+6S0Cf4CLV4Sz4/CnK7sYWTO0pNrU08FKIyiAjh8Ei5L4QWadwVkB44CNItRadFfoB7vS7pMgC7zSEM7DFYryyLbaWB++i/7hNmURve7DrWvKgSTZ5l1vJyTjpQHxkSI86vJ+qPLEABkAB+7PR5JAdnAdB2+L8y+dXQKZCfysw0gW1sA=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(8676002)(53546011)(508600001)(8936002)(54906003)(38070700005)(9686003)(86362001)(2906002)(38100700002)(5660300002)(7696005)(110136005)(33656002)(966005)(83380400001)(82960400001)(26005)(122000001)(55016003)(40140700001)(66556008)(66946007)(64756008)(66476007)(4326008)(52536014)(76116006)(186003)(71200400001)(66446008)(316002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: CohOQcGEbBXGUBZ56F4+2yZGjSic1//uVx8z7yqaTPfQjhP4TrgnlqC0sLayPhdXBZgy4p9EEHoth9aZVhQfpphF+q4w+UTeAo7kbi9qq95z05wkiO7SW3csYAe+35bSAisbg2awoxxnSjt+cQ7X6CfTVnvIPDR+6mnrD6HcHi0BJX9SwYBg5aJjybJART2z3F2dupGV91JswYoqVG2WSQxkbRGkOXZiKP6yMJN1A9civUJL73qpFy+akru14W7RFpfgM0b6nxxYAqWISNqVwJzNhuw+Gqskt4yz9XjBs+Eun5QZ2+B/+gVvNz0y8TrQhP+SLS6zohrUaA/Hds6EUIb6hW4H7GwRGuWzjTYBo+zrw+A/ujeuWE2gVUVN0Oz5GBiezDpZZ78S8/gdXGZV5+ZZV1zHvUnPjuBZPfoOBOeJf0MUSfQ4PHZAICnir6PbF+hmi2hhButP8EvzDaQkVmINxxiwhOUlCiJsFO1PD3D9boX4FOw+cnjW4f4m74EX9Yl7FQyDO711lpuZDEL+Be6lTHIbNTWa3Tnnhyl+JfvAJ74Jx8oxMh4rGB3hjQHFK3XM7GcwTp1EtrF65ohjnXDBxQ66aotBLp1MtAW8nJSlx3Yz9bcHkgNh+nlKui4i38OZDqnoUBkkYUMUTHZNfGOemnQYADyR9vWmMn5gQbBFBWtJrvnD+IdjLR6rFy7hWF/QGPYXlZjjoeZjIH0m/I2DHd0HH8fsWl9I700yc7nj+vYClnv7n+IjYPCdypLIXvsa4TU01OhdhRNkUMM3shNejeBqt8FoynlMUOFb127IaCJEj27YVeF4GeaC0BSc+8QqEey3zamYnnVeSLukOEdFFt/8++XGLCV/Hw/WB2mMXtPqpVuTwRPNcq/xl4O0pHhkSNw9rgMCzBfjRjP7QYS/XvX2UGu8e0Elf2qgAR+VVWphTntAEWxJGtSq+tUIxSlRBebXKnYfMI+sFY7l9EeWNbl36VHBe3H3mfuNPAdIlBiA0/rZIY5BSbr6O0AUm7nk7gl8rYaih8hYS2wUhEWjiPKn/TxH/r15KuErOzC/6aZJGsEkWCzSrIbul4dlEK6blPcqkovla42nqyima6sj5al5niiWkrbCIbzJZq7++aaQfwKQTpz4LWDcLYTvvz1jOfe+wK30SU4J/2NjOqt8YYTOjZmDhbbNAmTIiHeJka9FHM1g2jwcQYtmj79gD39yucvOuvpgo7u/3tw10hjJIHllRGO3k6zsGxaof9so+O4V+7fQ76PhB/kDdcTP02mO+qQLVpyEcm07C9rZKywVlW8etq6jVSNHF2OKUibueJK/I7ntVVapET63rRxz
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 704c1ec8-d899-4ccb-404a-08d9cfa04530
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2022 16:35:51.0268 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB8606
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/-gPpu_qqeFWMYnjdI96bG0kWBEQ>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-open-policy-18
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jan 2022 16:36:05 -0000

Hi Gyan,

[I am following up on the messages exchanged between Alvaro and you this morning. Thanks to both of you for that.] 

Sorry for the delay in replying (considering your original review date). Thank you for your careful review and comments/nits. Please see responses marked with [KS/AA] below.

> Comment related to Gao-Rexford model.  The Gao-Rexford Model only has 3 peer
types North bound upstream Provider, Southbound Customer and lateral same tier
level peer.  With the role capabilities, RS and RS-Client is added which makes
it slightly different but almost identical.  In describing the role types would
it make sense to have a graphical depiction of Gao-Redford model with the role
capabilities on adjacent peers to help explain the role relationship for local
and remote-as.  Just an idea to help explain the role capabilities. 

[KS/AA]: We felt that instead of a graphical depiction, it is more useful to include text to enumerate the peering relationships corresponding to various Roles. So, we have added (in v-19 to be uploaded soon that will also include changes to reflect Ines' comments) the following new text in Section 2 after Roles are defined:

   If the local AS has one of the above Roles (in the order shown), then
   the corresponding peering relationship with the remote AS is
   Provider-to-Customer, Customer-to-Provider, RS-to-RS-Client, RS-
   Client-to-RS, or Peer-to-Peer (i.e., lateral peers), respectively.

Please let us know if this seems acceptable.

>In the role correctness section scenario where the peer receives multiple role
capabilities to send role mismatch notification.  What if there is a timing
issue and the multiple are received after the BGP open and peer is established
possible sequence of events issue.  Is it possible the peer may not get a
mismatch notification if the peer establishes prior to getting a different
capabilities where a mismatch or problem exists that is missed that could
result in a route leak. I am thinking of possibly false positive or negative or
negative during BGP open  capabilities exchange.

[KS/AA]: We feel that Alvaro has already adequately addressed this comment in his two messages. Please let us know if you still have a question.

Regards,
Sriram / Alexander   

-----------------------------------------------------------------------
From: Gyan Mishra <hayabusagsm@gmail.com> 
Sent: Tuesday, January 4, 2022 10:44 AM
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: Gyan Mishra via Datatracker <noreply@ietf.org>; draft-ietf-idr-bgp-open-policy.all@ietf.org; gen-art@ietf.org; idr@ietf.org; last-call@ietf.org
Subject: Re: Genart last call review of draft-ietf-idr-bgp-open-policy-18

Hi Alvaro

Happy New Year!

Welcome!

On Tue, Jan 4, 2022 at 10:12 AM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> On December 21, 2021 at 8:01:21 PM, Gyan Mishra wrote:
>
> Gyan:
>
> Hi!  Happy New Year!
>
> Thank you for the review!
>
>
> ...
> > Summary: ... The new BGP role capabilities mismatch code 2 subcode 8
> > discussed on ML seems to have multiple implementations deployed and one
> > confined by Cisco. I agree that the authors should request a new subcode
> > for the role mismatch notification.
>
> To catch others up:  there is a confirmed case of squatting on the
> assigned subcode.  A consultation on the next steps is open on the idr
> list and will close tomorrow (Jan/5).
>
> https://mailarchive.ietf.org/arch/msg/idr/RBD3Z9YIboudGAIeJLS8L--p4BU/
>
> Gyan> Thanks for update
> ...
> > Nits/editorial comments:
> > Comment related to Gao-Rexford model. The Gao-Rexford Model only has 3
> peer
> > types North bound upstream Provider, Southbound Customer and lateral same
> > tier level peer. With the role capabilities, RS and RS-Client is added
> which
> > makes it slightly different but almost identical. In describing the role
> > types would it make sense to have a graphical depiction of Gao-Redford
> model
> > with the role capabilities on adjacent peers to help explain the role
> > relationship for local and remote-as. Just an idea to help explain the
> role
> > capabilities.
>
> The role definitions are described in this document, not strictly
> carried over from Gao-Rexford.  Nonetheless, a graphical description
> on the roles defined here may make sense.  I'll leave it to the
> authors to consider (if not too complicated).


Gyan> Perfect

>
>
>
> > In the role correctness section scenario where the peer receives multiple
> > role capabilities to send role mismatch notification. What if there is a
> > timing issue and the multiple are received after the BGP open and peer is
> > established possible sequence of events issue. Is it possible the peer
> may
> > not get a mismatch notification if the peer establishes prior to getting
> a
> > different capabilities where a mismatch or problem exists that is missed
> > that could result in a route leak. I am thinking of possibly false
> positive
> > or negative or negative during BGP open capabilities exchange
>
> All capabilities are signaled in the OPEN, so there's no possibility
> for receiving a Role Capability afterwards.
>

Gyan> Agreed.  The multiple capabilities received is mentioned in the text,
however as it's signaled in the open how would multiple capabilities be
received.  As the role capabilities are sent in the open , how can the
possibility of multiple capabilities occur?

>
>
> Alvaro.
>
-- 

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