Re: [Lsr] Last Call: <draft-ietf-lsr-isis-srv6-extensions-14.txt> (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

Alvaro Retana <aretana.ietf@gmail.com> Fri, 07 May 2021 13:52 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108713A2262; Fri, 7 May 2021 06:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VdCNSlG0L3p3; Fri, 7 May 2021 06:52:44 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 2DB113A2261; Fri, 7 May 2021 06:52:44 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id u13so10317152edd.3; Fri, 07 May 2021 06:52:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Sw6yuB6l0BMGSvrkfVbskXPt/vjdNKBHi/Gb9gQHgmc=; b=dSuPnhCF1sctpKLYlBa6oFbtVfTdGd4FB5p0KR87FuWZ/tIbmCVCjG4JJIh/fkVE2k 13HeIZDmKYrjuLxzyiJ2z3rJEaFH+Y96/b7uIFgflNAtTc0O9DoDWaZol8u0o9QxBgoq LBMp9WOQ3pBSj0bfZhG41tt9mRhhu5DK+AA3u2oqly9+aTnut/xTHCfjjHIUAY/g11bf JPJM/LtCqc+3+7LH/GoDeFhJTVk5EWOlZzhLU6AbB94PAWqGM59FBGTUAm+myU7CM5H2 Gv0jLsyhOeTqZxrlf9iB/6fAWUnNRUnEraH9DeNubgHG5SyLmK94v4nUzkTqy2HHr4oF +Ggg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Sw6yuB6l0BMGSvrkfVbskXPt/vjdNKBHi/Gb9gQHgmc=; b=JYBKYp+opE8XioSx219KnE2RI6egaRcTF9tCWOenfWI6KyOKRwMXCvEEKom7hCog/X s0qhwY/Nf/U3kF6+FCaVyV7C6wmYsA3BesjudzVZJ+DWpewfoP3JrKweqzSzMxdmSq10 io3i9vVAc1mAVwyhmdlu0KSINCZv4Iw6xbXEGcrhSjH1TDyeLMPo8gTZ/kDHuXQ8f2Ec NlRfV4jisNpbl0oLDoF7cuf4NECxfThcn4OJ+OJIyfwjiW2LcnTHuFU1+dC8r1L1itCH 4n6adwicHf23G0Wg60gKZ+htEHTVh3B9T8auY5/GiuVGYWBUlG0k6UzxCJrYTZLUzEAU 1i6A==
X-Gm-Message-State: AOAM532yXW0NMByi17MDXmCB8o4A5fBnsu64xtmAs4kthnuDawqfJcqF Qg6fUEMIhlrVjB3ykFcjo+JM7etYEzrmLwjqHUk=
X-Google-Smtp-Source: ABdhPJzAIbqBl3GIMzNgnxE0y3R5ByhW9iR160FKFuRu2+2x7J+PBSoZmPb2ScncQQwV3s20+eH0xvYBTECaJTPVjG8=
X-Received: by 2002:a05:6402:310a:: with SMTP id dc10mr11540914edb.38.1620395560775; Fri, 07 May 2021 06:52:40 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 7 May 2021 06:52:39 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <98456c8b-42dc-a387-0a18-f7921a94aeb1@cisco.com>
References: <161912242429.12485.17590245376033356793@ietfa.amsl.com> <AM0PR07MB638668F6AC767504D0534925E05B9@AM0PR07MB6386.eurprd07.prod.outlook.com> <98456c8b-42dc-a387-0a18-f7921a94aeb1@cisco.com>
MIME-Version: 1.0
Date: Fri, 07 May 2021 06:52:39 -0700
Message-ID: <CAMMESsyzYoS=rR4RV1exdA-5DTMv6j2muNqrgWJ6oNocVgT0ug@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>, "chopps@chopps.org" <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="000000000000cbb4ce05c1bdbd05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/JBM-xnNlicYKp-1g6eq4fna6UGQ>
Subject: Re: [Lsr] Last Call: <draft-ietf-lsr-isis-srv6-extensions-14.txt> (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2021 13:52:47 -0000

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm
requesting it to be put on the May/20 telechat, which means that we should
have a resolution and updated draft by the end of next week.


Thanks!

Alvaro.


On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppsenak@cisco.com) wrote:

Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the
prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator
has been redistributed or not for a correct operation.
>
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2
to L1.
> ** So this end-sid will not be used as we know that it is redistributed.
>
> * In the other direction (L1-L2), we only know that a locator is
redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised.
> ** This means if the operator does not configure advertisement of the
prefix-attribute tlv, ISIS could potentially use an end-sid which does not
terminate on the expected node.
>
> * Compared to sr-mpls, a prefix-sid has the R flag indicating it is
redistributed.
> * We don't have that for locator end-sids.
>
> Relevant snip from " draft-ietf-lsr-isis-srv6-extensions"
>
> 7.1. SRv6 Locator TLV Format
>
> The SRv6 Locator TLV has the following format:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length |R|R|R|R| MT ID |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Type: 27
>
> Length: variable.
>
> R bits: reserved for future use. They MUST be
> set to zero on transmission and MUST be ignored on receipt.
>
> MT ID: Multitopology Identifier as defined in [RFC5120].
> Note that the value 0 is legal.
>
> Followed by one or more locator entries of the form:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Metric |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Flags | Algorithm |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Loc Size | Locator (variable)...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sub-TLV-len | Sub-TLVs (variable) . . . |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> Metric: 4 octets. As described in [RFC5305].
>
> Flags: 1 octet. The following flags are defined
>
> 0
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |D| Reserved |
> +-+-+-+-+-+-+-+-+
>
> where:
> D-flag: Same as described in section 4.1. of [RFC5305].
>
>
> G/
>