Re: [Idr] [draft-ietf-idr-segment-routing-te-policy] Error handling for Explicit NULL Label Policy Sub-TLV

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 03 July 2019 12:29 UTC

Return-Path: <ketant@cisco.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 712B2120157; Wed, 3 Jul 2019 05:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fSEKaHkg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sPKUsMeG
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 dquTEFJAad5k; Wed, 3 Jul 2019 05:28:59 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103DF120077; Wed, 3 Jul 2019 05:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20728; q=dns/txt; s=iport; t=1562156939; x=1563366539; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AOH/07ywL+bFVBF7+Nphzfb4a/iZ5DG9JkNa9Q+E/54=; b=fSEKaHkgC00JPekJJa9rx6NXhTW/KyQmJN4ktWSAJvh7T9yJf7T3ENig u/g34wRDk1d6fAOs+6rxg8qCMe9gsgEhk1C6JXLTg3t9yxIgPsOUf6VMK HIC6/3SY4QgNmycYtgElnBJ3T4WKHksHOIoRxrU2uRFvLFpHe1eogel2b 8=;
IronPort-PHdr: 9a23:5AZi6BTIcYIsc+nUPhnIe2IL09psv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOi83AM1ESHdu/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIAAAonxxd/5xdJa1mGgEBAQEBAgEBAQEHAgEBAQGBUwUBAQEBCwGBFC8pJwNqVSAECyiEHINHA4RSiXKCW5JyhFSBLoEkA1QJAQEBDAEBJQgCAQGEQAIXggsjNAkOAQMBAQQBAQIBBW2KNwyFSgEBAQQSEQoTAQE3AQ8CAQgOAwQBASQEAwICAjAUCQgCBAENBQgagwGBHU0DHQEOmVQCgTiIYHGBMoJ5AQEFhQ4YghIDBoE0AYteF4FAP4ERRoJMPoJhAQECAYFgFRYJglQygiaOaIR8llsJAoIWhlaNRIIrhxyOKo0whz2PdgIEAgQFAg4BAQWBUDg3gSFwFYMngkE3bwEHgkOFFIU/cgEBgSeNAgEB
X-IronPort-AV: E=Sophos;i="5.63,446,1557187200"; d="scan'208,217";a="587092445"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 12:28:37 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x63CSbPb021463 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 12:28:37 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 07:28:36 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 07:28:35 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 07:28:35 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AOH/07ywL+bFVBF7+Nphzfb4a/iZ5DG9JkNa9Q+E/54=; b=sPKUsMeGJ19z1gWyb7KW+50MHdQY4CXd+w43PuI7gAM+wZuyPyPDyAigGJxxoAgKhcxZ8jtT85jmJnFzx9j8yarQ9YMqdg2tSJRUF1WFdeLLXcUwOt13J5lF5MpNDTPyBtRAh/ECoZQudaGLunikwIU1irwJbmg399fKgCch9L4=
Received: from DM5PR11MB2027.namprd11.prod.outlook.com (10.168.103.22) by DM5PR11MB1433.namprd11.prod.outlook.com (10.172.35.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.18; Wed, 3 Jul 2019 12:28:34 +0000
Received: from DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::3cb3:24e6:1ba8:bba5]) by DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::3cb3:24e6:1ba8:bba5%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 12:28:34 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Przemyslaw Krol <pkrol@google.com>, Manoharan Sundaramoorthy <manoharan@arista.com>
CC: Nandan Saha <nandan@arista.com>, "draft-ietf-idr-segment-routing-te-policy@ietf.org" <draft-ietf-idr-segment-routing-te-policy@ietf.org>, Paul Mattes <pamattes@microsoft.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [draft-ietf-idr-segment-routing-te-policy] Error handling for Explicit NULL Label Policy Sub-TLV
Thread-Index: AQHVC7sFXRcjrrOoL06T2K2cL/MKR6ZvmlaAgABqDgCAAB7NgIBI+Ydw
Date: Wed, 03 Jul 2019 12:28:34 +0000
Message-ID: <DM5PR11MB2027AA578DF4B998E671CEB9C1FB0@DM5PR11MB2027.namprd11.prod.outlook.com>
References: <CAE+itjfH=EHN=Fm-in0v0r5r1wHKOz+Kd0mGBJfm6cLjVKNTNg@mail.gmail.com> <CACH2EkVGD3ZX3ZdX9dS9tPoPrDtqTvHnQD4VezrOED3fmVj4jA@mail.gmail.com> <CA+W7bqevhivu0KBbjwcRirxpL2HyZ0Hc7hfapOzisQvqf0jK6w@mail.gmail.com> <CACH2EkXwAbx-1ZZFbxBr=TN2j07WpAG2Krsq8ojhrKANdOZ-dQ@mail.gmail.com>
In-Reply-To: <CACH2EkXwAbx-1ZZFbxBr=TN2j07WpAG2Krsq8ojhrKANdOZ-dQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com;
x-originating-ip: [2001:420:c0e0:1008::ba]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dad10e13-8fcc-4a45-742b-08d6ffb1f757
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR11MB1433;
x-ms-traffictypediagnostic: DM5PR11MB1433:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR11MB14339EA7E6E823F926E0A003C1FB0@DM5PR11MB1433.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(189003)(199004)(53936002)(229853002)(73956011)(99286004)(476003)(76116006)(316002)(486006)(71190400001)(256004)(71200400001)(14444005)(6506007)(236005)(11346002)(446003)(7736002)(66446008)(66946007)(4326008)(66556008)(66476007)(110136005)(54906003)(14454004)(68736007)(25786009)(8676002)(33656002)(9686003)(6306002)(186003)(2906002)(8936002)(54896002)(64756008)(478600001)(966005)(6246003)(55016002)(102836004)(6436002)(45080400002)(7696005)(606006)(6116002)(790700001)(76176011)(74316002)(81156014)(86362001)(81166006)(52536014)(46003)(53546011)(5660300002)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1433; H:DM5PR11MB2027.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6FZCBBbA47JVZFK9s0DTpRDzi/LHIK/B8/YquriKEjznrxbnAMQDjzdUAJmIvqKihWXJHcdosURW47K1h0NKkH+tBgGB4DRT6B/0rswGetgJMYW+bcuPsOhwNgZ82KWakmbhwywl7DZzfeU1v/mJikFaN2gILkxxm8X9uaf/CrLShef3lau+eQDPQkQWOvtbpIdQN6+qCviiVekRQvnQ74FM1QHinqvHAaTA5x1v9t0E9+XbFoOIPY5s/Wnk6vY/0buI8PxRW/XY5WFQ0gwsQ8BIYP2aF1XFFc6hBZXmONotsUMB+S1KtdzMZlQc/i5mO0iuIYxFm5knE43cOg5g4jAJedFGd2J5432fdbkN2EXd8zOyKSwC0DZl/3AOSIZDFd+KFj70AZBwvLISTcImRDAKJIPXzXwxQSrjp/lS6qo=
Content-Type: multipart/alternative; boundary="_000_DM5PR11MB2027AA578DF4B998E671CEB9C1FB0DM5PR11MB2027namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dad10e13-8fcc-4a45-742b-08d6ffb1f757
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 12:28:34.2771 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ketant@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1433
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/V8j6Nnc_MQBiXP3DPbGfcJ54gZM>
Subject: Re: [Idr] [draft-ietf-idr-segment-routing-te-policy] Error handling for Explicit NULL Label Policy Sub-TLV
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, 03 Jul 2019 12:29:01 -0000

Hi Mano/PK,

I also agree with your proposal for (1).

Regarding (2), I also agree that it is better to treat the values 0 and >  4 as reserved and if these values are used then the headend can ignore the TLV (which would actually be falling back to local config, if any).

I would request the authors to please consider updating the draft with the same if they agree.

Thanks,
Ketan

From: Przemyslaw Krol <pkrol@google.com>
Sent: 18 May 2019 07:29
To: Manoharan Sundaramoorthy <manoharan@arista.com>
Cc: Nandan Saha <nandan@arista.com>; draft-ietf-idr-segment-routing-te-policy@ietf.org; Ketan Talaulikar (ketant) <ketant@cisco.com>; Paul Mattes <pamattes@microsoft.com>; idr@ietf.org
Subject: Re: [draft-ietf-idr-segment-routing-te-policy] Error handling for Explicit NULL Label Policy Sub-TLV

Hi Mano,

Oh, I see. Thanks for clarification and apologies for my irrelevant comment then.
FWIW, I support your proposal to consider these values as reserved and fallback to local poli..., erm, behavior defined by config :-)

pk



On Fri, May 17, 2019, 17:09 Manoharan Sundaramoorthy <manoharan@arista.com<mailto:manoharan@arista.com>> wrote:
Hi Pk,

In 2(b) we meant, "For values 0 and 5-255, treat as if the Sub-TLV was not received and take default ENLP action that is configured locally" (or) "if these values are to be treated as illegal, then do TAW".

Thanks,
Mano

On Fri, May 17, 2019 at 11:20 PM Przemyslaw Krol <pkrol@google.com<mailto:pkrol@google.com>> wrote:
Hi Nandan,

I personally agree with your proposal for handling multiple ENLP sub-TLV (1). It's clear and consistent with other similar cases

In terms of ENLP = 0 || >=5 (2), my concern regarding 2b (fallback to static) is that there may be multiple instances of BGP policy (different advertisers) with the same or lower preference and valid ENLP values. Failing back to static would basically skip those BGP policies and "bypass" policy selection. I suspect it's undesirable. For this reason, treating it as reserved (2a) sounds to me like a better option. Unless you really meant ignoring offending policy and moving to the next one (which can be static or BGP, depending on the selection algo), but regardless, 2a) seems safer and less disruptive in the future (if/when we need ENLP >=5 ).


thanks,
pk

On Thu, May 16, 2019 at 12:42 AM Nandan Saha <nandan@arista.com<mailto:nandan@arista.com>> wrote:
Hi folks,
 There error handling for the ENLP sub-TLV isn't defined in
draft-ietf-idr-segment-routing-te-policy-05 [1].

There are 2 things that need to be clarified:-

1. The behavior when ENLP sub-TLV occurs more than once:
  For this, my preference is to add text like we have for policy
priority sub-TLV [2] (and some other sub-TLVs), mandating only one
occurrence and treat-as-withdraw when present more than once.

2. Behavior when ENLP value is either 0 or >= 5.
  The only meaningful/legal values defined now are 1-4. My preference is to
2a: mark other values as reserved for future use. (We could mark them
illegal but that'll rule out trying to extended them if ever needed)
and
2.b: Upon receipt ENLP = 0 || >=5 the headend call fall back to local
policy. (If we go down the route of marking 0 || >= 5 as illegal, we
can do TAW)

Please let me know what you think, and if this seems reasonable.

[1] - https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.4
[2] - https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.5

Thanks,
Nandan


--
Przemyslaw "PK" Krol |
 Strategic Network Engineer
ing | pkrol@google.com<mailto:pkrol@google.com>


--
Thanks,
Manoharan