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

Manoharan Sundaramoorthy <manoharan@arista.com> Sat, 18 May 2019 00:09 UTC

Return-Path: <manoharan@arista.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 273D51202AE for <idr@ietfa.amsl.com>; Fri, 17 May 2019 17:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arista.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 FFjyJtgn59JQ for <idr@ietfa.amsl.com>; Fri, 17 May 2019 17:09:29 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 7BA13120284 for <idr@ietf.org>; Fri, 17 May 2019 17:09:28 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id u27so6473992lfg.10 for <idr@ietf.org>; Fri, 17 May 2019 17:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5EOoVNiBTkukhCdykjvEbMKhyx00sq3qH2Cyy9O94NU=; b=n14aMUSfZS8JpVg//J05/C8vHO2UrY42Qs/VkuiNIn5dYeAE5V2yA80MSGg7cPUjso zw+XpXJ2rkG3LRvvCUQX1vG56bik0TZvajIIOrdejPNX7i/CMK9vc7z2aqDHeMMYqr4m fb3Me5sIwIaMe8ectDUTn/CR7szcgnCDI6/C50e7J8FKQkVXelKVnFivrpPVRkKAzf5W TBaz2+3B9IOVLoLS8Xe5blXxeHFOtl88kN/QgOC6O14ePwsLsBjo1iA+HwvTDL9pSBlQ OzO1O4dPXV0nIJcVDRKyN/fmAhB0Gg11VrNGZBg08pi2NEZUcyGpPzCH9Cb12LO3DZkf KFUA==
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=5EOoVNiBTkukhCdykjvEbMKhyx00sq3qH2Cyy9O94NU=; b=h/aZCkesh5fMrcuNS/fEu8X60ltIF142ZIbDbqchkb/pB3EZ3Y6i4CgCEEj1C2rJl5 SLNWpeLdO2wu/6U07HApycS+qPLpJau39MjfuoWZZvQqpMZLNGlQfAKcGipUFDpQ8ogw X9XofrXdbR+KIxdfxyWgIBZcHT5ri/+abL4fTR12wMMG4kWHnYw3gzS6sPP5CHkOHFPz wuoxquETG1O4UmT/krj/2eqY/2QFkCapHnMu3KFYjeBMRiiHRfKoMjFrJT0g8fUgGndc BJuT92ghU8S2EmdIdxfZYq62F9z+0b78M9DEuFwjCtyWOYw8kyWPmomPRQUEUx50tFsW G2Hg==
X-Gm-Message-State: APjAAAWUfRb5khBt/3POBYy3RzY2YW+v4n+cRkl7IiDz2W4+L44q8qZh hox1XJYA3UYiK7pKqT4N38yHKsLqzaBh4g2BX+m4lg==
X-Google-Smtp-Source: APXvYqzpSZZNffJQsVOJ9113wXxTbjrfphqqbP7qmR/+RNZjoUvdhvCRQJUsdCQWSYly5A8MbBg8wyDkM8KQcJdekzs=
X-Received: by 2002:a19:c20e:: with SMTP id l14mr9726202lfc.5.1558138166648; Fri, 17 May 2019 17:09:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAE+itjfH=EHN=Fm-in0v0r5r1wHKOz+Kd0mGBJfm6cLjVKNTNg@mail.gmail.com> <CACH2EkVGD3ZX3ZdX9dS9tPoPrDtqTvHnQD4VezrOED3fmVj4jA@mail.gmail.com>
In-Reply-To: <CACH2EkVGD3ZX3ZdX9dS9tPoPrDtqTvHnQD4VezrOED3fmVj4jA@mail.gmail.com>
From: Manoharan Sundaramoorthy <manoharan@arista.com>
Date: Sat, 18 May 2019 05:39:14 +0530
Message-ID: <CA+W7bqevhivu0KBbjwcRirxpL2HyZ0Hc7hfapOzisQvqf0jK6w@mail.gmail.com>
To: Przemyslaw Krol <pkrol@google.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
Content-Type: multipart/alternative; boundary="000000000000ef42a905891e4f0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/K3rD-ySxHWZ4Vw_yGfuS-NGcTMQ>
X-Mailman-Approved-At: Mon, 20 May 2019 04:00:31 -0700
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: Sat, 18 May 2019 00:15:31 -0000

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


-- 
Thanks,
Manoharan