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

Przemyslaw Krol <pkrol@google.com> Fri, 17 May 2019 17:50 UTC

Return-Path: <pkrol@google.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 3A8661200E6 for <idr@ietfa.amsl.com>; Fri, 17 May 2019 10:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level:
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Tp9h7bFCny5J for <idr@ietfa.amsl.com>; Fri, 17 May 2019 10:50:17 -0700 (PDT)
Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CFB12001E for <idr@ietf.org>; Fri, 17 May 2019 10:50:17 -0700 (PDT)
Received: by mail-yw1-xc32.google.com with SMTP id n76so3085123ywd.1 for <idr@ietf.org>; Fri, 17 May 2019 10:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LKY/LQ+2xfIaUScdF/+z8POrhXqX6vdnPuyL2zOlIFw=; b=nwK+q8PF71Gt+8XIYcdP3SPrg2w61tB5f7LP3R/FLh5r7Xq19AAcj2cbMEshVguVwy 2lBb+mrkGvnBXaAjhrP136BBBn8yy420J4UZlTPQK8++IFHWmbyw8AVZyM4MpA55irIr zSUOVtTOlgFV78ofhG22I337RcpEJ7PtIbKWy+5f37GwvMWs39B2voVPVKqKkA4hxg3P kDeafmzF8rK2U0Urxgupb+tCnVOa/AijJ/uzBevHhzHXgTWlUJYRAMtJYUMjDgRZohG9 ipfgGUjUwR8JzOyamp/xgE8z99tqSPryfbzKy+wJox469YG41C/T37ct7/utFpVzadp2 E0QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LKY/LQ+2xfIaUScdF/+z8POrhXqX6vdnPuyL2zOlIFw=; b=qVYLaUMp22T2PNDwFEbrIr0OqnLV9XJ20UUfkAX/MmjxSEgARL6l/ZqgjAvTW2aPSU Pjq7ARk3F3JnmmtzVBpGe1LoWoJtMl9zBeA1omksc4hHxDvYjZ7DSwGetQyFOHwnnFWh fl1eYnxk7FLkGNKwLRJCCwRn8imnUuCX/3x0PggLzwVZQCFNsFgOCWshDw1+zKhTiqyc gHPuJ5xWmrznDze1i4CmUMSmbzQMVxUol5CgWstHfuZL+SNC2SnOoEAw7xSpjsQp/K+8 DDPmWbGhodUNNZqhFKp1hHbDMZOlKVcHlTWzz2+W1YGIAjEk2favZCvBmblJgt1Sgp2V IKmQ==
X-Gm-Message-State: APjAAAUX0pDJRD+FS0ibZdHoq6bw96I2w9+kK+p+R13BMxklJjO0V47b iVDx0uJNwRHo0KUk0cSrcKFm1Yr580CRXx8zlS+P3Q==
X-Google-Smtp-Source: APXvYqyY7VAO1IL/U/WSdy/8pp6nuF4jCP/Xq/iF/BW67cpir47mUqDovKiAbP6jPJrO7R3eWuip1dfU+7MAEf1vioA=
X-Received: by 2002:a81:a549:: with SMTP id v9mr1658197ywg.3.1558115416391; Fri, 17 May 2019 10:50:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAE+itjfH=EHN=Fm-in0v0r5r1wHKOz+Kd0mGBJfm6cLjVKNTNg@mail.gmail.com>
In-Reply-To: <CAE+itjfH=EHN=Fm-in0v0r5r1wHKOz+Kd0mGBJfm6cLjVKNTNg@mail.gmail.com>
From: Przemyslaw Krol <pkrol@google.com>
Date: Fri, 17 May 2019 10:49:39 -0700
Message-ID: <CACH2EkVGD3ZX3ZdX9dS9tPoPrDtqTvHnQD4VezrOED3fmVj4jA@mail.gmail.com>
To: Nandan Saha <nandan@arista.com>
Cc: draft-ietf-idr-segment-routing-te-policy@ietf.org, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Paul Mattes <pamattes@microsoft.com>, idr@ietf.org, Manoharan Sundaramoorthy <manoharan@arista.com>
Content-Type: multipart/alternative; boundary="000000000000ea35500589190366"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zxP3VxY4iRgGvIx5HDpdBzk1P40>
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: Fri, 17 May 2019 17:50:20 -0000

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