Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Wed, 09 June 2021 16:09 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896563A1D07; Wed, 9 Jun 2021 09:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.387
X-Spam-Level:
X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_HTML_ATTACH=0.01, T_SPF_TEMPERROR=0.01, 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 StmdpLJnJjhn; Wed, 9 Jun 2021 09:09:15 -0700 (PDT)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2098.outbound.protection.outlook.com [40.107.91.98]) (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 AC8EA3A1D02; Wed, 9 Jun 2021 09:09:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SvH3kDwCL3PwiiHysjm5KJMGVGuAJehJ/Blp96xDhP8p3ZXfT0vQWAjClnwru9Nn6bADwrGV0glRMqYoQjm5YQub0n1yo8V9rLa3d3OortmAaoXIsgucF2/i7Pd2G9hAloFJq4djTHw5s9paPrwxgdiAPtJLA7VGO/gCIsptf+PoYh6pRaDo7g0WtsDHebKCQTFFkLsbXQsWLBRMqES29ge/j/W2ilXZH+mu3HCW+dQyJLuQuuhJ6xIBgMdWoD7ozu3x0EQYZhtwxn4cAdGQhgYlahRHhp59PqugHWXZxaLIdahgGRmHYx6kKWe4JTanxFP9SFR0VJfN83J0+yDy2g==
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-SenderADCheck; bh=/xuZIMSYE45m6gZVkFowTPFhstT17iG5ShfKtB9kID0=; b=m8RZgn0+On0HgfcB/uHRQPuO89gAi0JSLqHqQOAlaWVLCEYHY9M0vAWgyUHg1uRpWWpWb64PFVJRDbjKGnRZWgkX413CcwH52YB/FczPZSCEp1HYJGqo6hcaTCdJ9cG8UN9agDLDcS8VnZKu+QTnn2iBfNRteP+nBHXBQkCt4cRH8fL9EUBoM9Tb+DRVhaQiwYLlo1pWYJ0V6bi1+oagGY1vx8tmZlwjLnrsNmCyseY+krjvPQgJfV1H0e31M6h25pkdOjE5jRj2GWRTmqdh8xXPDDCR5Bz51W20qnYX3VWGwHiDH4IuxKT9ly01UyepPk8oHraHaFJiT3ffBRSupg==
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=/xuZIMSYE45m6gZVkFowTPFhstT17iG5ShfKtB9kID0=; b=tCDu1db1z010ieJSoq5MN/BSmFTjoScD0UdZMOg/16livXgW8Oj4RIX9h5XU6GmkBwKyqKq9U3zuGq8GDFSFrOaIAp/AU5dOd5xVkz5f3iwwNp2JydTbnzo3ZfQQILTwWs5OGK4KNtK6AMmw0EEG/5icVVEnyv2wWXhtxv400eg=
Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA0PR09MB7003.namprd09.prod.outlook.com (2603:10b6:806:75::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.22; Wed, 9 Jun 2021 16:09:09 +0000
Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::b528:53a6:340e:8da8]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::b528:53a6:340e:8da8%4]) with mapi id 15.20.4219.022; Wed, 9 Jun 2021 16:09:09 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Mach Chen <mach.chen@huawei.com>, Alexander Azimov <a.e.azimov@gmail.com>
CC: "draft-ietf-idr-bgp-open-policy.all@ietf.org" <draft-ietf-idr-bgp-open-policy.all@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Thread-Topic: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt
Thread-Index: AddHqF05jAuFF5QzTsaQPC2aQyKdxQMVFPwAABkaRgACNuaAVg==
Date: Wed, 09 Jun 2021 16:09:09 +0000
Message-ID: <SA1PR09MB814231FB0B10E55ED328557B84369@SA1PR09MB8142.namprd09.prod.outlook.com>
References: <e45c1b2dcd1a493f9022bb1d9fff40bb@huawei.com> <CAEGSd=ArLeVQy7_p7S5gKfPazFA3Y9-6uzAN-ftogHMK-540cQ@mail.gmail.com>, <5b1c53aa2e9c4a18b03b95fb7b00abf2@huawei.com>
In-Reply-To: <5b1c53aa2e9c4a18b03b95fb7b00abf2@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [129.6.220.33]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 12fde771-d61e-4bea-ec41-08d92b60ea51
x-ms-traffictypediagnostic: SA0PR09MB7003:
x-microsoft-antispam-prvs: <SA0PR09MB70035215DE2013A3805C990684369@SA0PR09MB7003.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yJyDxzR4b4l3Clep9i6V9/uLp+CaV9PY+OTmvA3UOfR44OeR/xsi2uGOYJIM1MXLu2Gjh+HP84wIZfDaXyce+femg/FofWi6u6QCVocZtLDu1DiMWzwi7yN96CD/AQfYmOBxCy6uEqee1axJFAUsRC7yxJAvMgl1/2KC0BJAhXlAMnsXQM+CLSl2GnNuNUWhWAXRBYc5lkqb6whT06jQF5Z6wMFeXJvhFWzmJgJWGYeTECwYcmCoOGBqPFiZ1uFxKtNe8BqafCJ3mPjSo+pBnaW8gL96HArjx8DOA2HG4kXafubi4yH6GHtgNTHb56YVyE93BuPI3gbe8YxBXhDXoj18sqMowE06cpnkFu4HAkETUKcFRjtsVrNCiMv2vuF3xVpUZJJHQVdKiyz0amXkvqFXTuZSC6g8xlxNfRDBUw2fyRq5vCDtHytYXG8F1m734PWQMt/PxUGL58OKZ/tDML/KY/VXE1ZWo92rGeQlVSRdslbLm3nqsgnz1PrJM0DDtCwvURRbSkLncQqa/jJjIU+g+OH7laQ/2lIqHvZnHRP+r6ItBCqDxDJNzSTRaagvF/kNzbuI2frqWulz6jDoP9ucv/dsN4rFHpyMrgtckiXHFtSkmAC6R83XszQf6VBDaoHUyHjerUaXUnFkBlMmVRtBQ6dF/aG1YA18oP+gdhrBBOvqoVbXKOne8hXqDoiKBNp8ZJ5E4ipv5sQXByPdQQ==
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)(39860400002)(136003)(396003)(366004)(376002)(346002)(52536014)(71200400001)(9686003)(8676002)(7696005)(54906003)(110136005)(122000001)(5660300002)(26005)(55016002)(2906002)(76116006)(91956017)(66446008)(316002)(86362001)(186003)(6506007)(478600001)(38100700002)(64756008)(66616009)(66476007)(66556008)(53546011)(99936003)(83380400001)(4326008)(33656002)(66946007)(8936002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: mG0qgUHpyFPBNy0R5EY0XvtPRbbSDCD8HbjjWQiJ+OYIwP5hw5M+KWwF9e4tbm7kz8ZS352eEe8jmDH5bXA7+huBBtj3Wj2AvTNZzhanBCfjG3ISSe6FG8R45YwNb8DUDEO8Ihkw+V/crJtuLcFXjtF3SQTzq6pUfIJAigAuqxaK43iUkvEwvIi4MB+rsYa8AbpHjnwJndagMclNRlgbM72DDr7iyAk6p0t9LtE1clWwv4gmhrW/K2nduxEAvW/DIsX8uccn0RIn8QBYNdeG1wWY8kHjpIACuyfcKz9xfjYXzMQrN7o5D2rs9R3kk7vv9eXXOoPf71UHfAFaIMBE1XHH9ln/Rt75iZ+c4IU63o9NXwGKN4LMS56yZ00q2lJv76lQcZyRh0FU58KPGva+mLyGw4YVObGMjhDhc9tkon/KnGNigezMbzQKcPNtM3mwXTixmYmHQncXv1l2mFwivDjWS15AVDWaNZ8FDrd/2++xYdBN1RmdqaNQEQrsjUHsyGwTO6p3RdKjDjFBZyU2WsxaEcz43HIBfSIF4OHxVm8kjW9ru9D2WDjJPrG12J3N/MpQvU60eRb2DrUGDjL2uGEu2Ao1zHlfQlPmAJWJ4TziwZm1HEUWe0EjtIfQiESVutbylmwQCFSC01a/b2Wr5+qBhal10iCrW/Vmia0922rB/UtuqmITwAyKeqBpCoiHhs4U9fSx4qcNGNwaWuV8gkloAwHAVPCwHWa2mQLIwOfO+JNs2uFvQAj1Lh39dvi0PZkzDSdvbK5DhzQYBBF3skoxrxpM3NN1a3c57VsYXbd0u6yx8IHYtIBRA+2VEkAgHPBDvwcB0r7yzOBXDp7yJuBJig9cfegBxBCV/0fBikX2KWLeW6mC38Lv+rdQqsdXAsT90hm9oHLQcaq3suU/V+q1gn73kNiMyCTHEYCO5R66dZ6SGjxQjpuPkVpiVnOhhpIYvTirDULY4VyOsz5i/iqLNkoIr9/F8iFYcf+gl6oM/JJhhg7TtzIrgVX+yS/HELWuh1bZbHQyQgQ3xPK9WiiQMkyJoaJMo+trf6oWYRHOtpvnG5b+y9VBMfOvIpxJ9dFHARZhuy/1vzqRolwJ6ShX7oG1eKTpw4KY6Evp6rHpmUqimObIoGcf4jJkewEMCtuE+SoH2xa+MPbQyyWHGx85ufvIDINwDmUyCM1wYxJfUbDczfZrmetS5xjCGlDSzCGo/lj4ZvWyerTgxEj+A+jgUZqUC5EgPISnqXLCs/RUUqjE5f43fIki1tMb46ZASB3EJwTir/spD7xn9Xh5le/eYU9RydVeRVLeKZADhFc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_SA1PR09MB814231FB0B10E55ED328557B84369SA1PR09MB8142namp_"
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: 12fde771-d61e-4bea-ec41-08d92b60ea51
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2021 16:09:09.6105 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR09MB7003
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/g6lvPdslEM781Jo14EsJ9ERYccM>
Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2021 16:09:25 -0000

Hi Mach,

Thanks for your patience. Alexander and I were able to complete the discussion between us. 

Please let us know if the following two proposed changes would adequately address your comment:

We added the following new paragraph in Section 5.1 (just before the OTC attribute processing section (Sec. 6)):

   In the case of a neighbor who doesn't participate, the BGP Role is
   configured unilaterally based on local knowledge of the peering
   relationship.  (Note: This applies only to the default non-strict
   mode; remember that in strict mode, the BGP connection is rejected
   for any non-participating neighbor.)  The only thing lacking would be
   a mutual confirmation with the neighbor about BGP Role (this is
   permissible for backward compatibility in partial deployment).  The
   OTC attribute processing (Section 6) remains unaffected.

In the above, if you feel normative language should be used, then we can
s/BGP Role is configured unilaterally/BGP Role SHOULD be configured unilaterally/.
Please let us know. 

We made the following old text / new text substitution in Section 8:

Old text:
   No Roles SHOULD be configured on a 'complex' BGP session (assuming it
   is not segregated) and in that case, OTC MUST be set by configuration
   on a per-prefix basis.  However, there are no built-in measures to
   check correctness of OTC use if BGP Role is not configured.

New text:
   No Roles SHOULD be configured on a 'complex' BGP session (assuming it
   is not segregated) and in that case, the OTC attribute processing
   MUST be done relying on configuration on a per-prefix basis.  (Note:
   The per-prefix configuration of peering relationship is currently
   done to handle 'complex' BGP sessions.)  However, there are no built-
   in measures to check the correctness of OTC use if BGP Role is not
   configured.

I've attached a diff file that highlights the above-proposed changes 
and also the changes in response to your nits. We'll plan to upload 
a new version -16 after we hear back from you on these proposed changes. 
Thank you.

Sriram
________________________________________
From: Mach Chen <mach.chen@huawei.com>
Sent: Saturday, May 29, 2021 4:03 AM
To: Alexander Azimov
Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org; idr-chairs@ietf.org; idr@ietf.org; rtg-dir@ietf.org
Subject: RE: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt

Hi Alexander,

Please see me response inline with [Mach]

From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alexander Azimov
Sent: Saturday, May 29, 2021 4:05 AM
To: Mach Chen <mach.chen@huawei.com>
Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org; idr-chairs@ietf.org; idr@ietf.org; rtg-dir@ietf.org
Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt

Dear Mach,

Thank you for your comments, all nits are already applied.

[Mach] OK.

But it proved that different authors have a different reading of your comment related to section 6:
Section 6.
It does not specify how a speaker handle a route with OTC attribute but the sender's role is unknown.
Are you speaking about the OTC processing in case of the absence of a locally configured role?
Or does it about receiving OTC attribute from a neighbor that doesn't participate in the role negotiation?

[Mach] Actually, in both cases, the role of the peer is uncertain, if so what will the ingress policy and egress policy be? For example, regarding ingress policy, how to handle a route with OTC attribute but not sure the sender’s role. And regarding the egress policy, if the peer’s role cannot be determined, Whether the route should be sent to the peer? Should the OTC be kept?

Best regards,
Mach