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
- [Idr] [draft-ietf-idr-segment-routing-te-policy] … Nandan Saha
- Re: [Idr] [draft-ietf-idr-segment-routing-te-poli… Przemyslaw Krol
- Re: [Idr] [draft-ietf-idr-segment-routing-te-poli… Przemyslaw Krol
- Re: [Idr] [draft-ietf-idr-segment-routing-te-poli… Manoharan Sundaramoorthy
- Re: [Idr] [draft-ietf-idr-segment-routing-te-poli… Ketan Talaulikar (ketant)
- Re: [Idr] [draft-ietf-idr-segment-routing-te-poli… Kausik Majumdar (kmajumda)