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

Peter Psenak <ppsenak@cisco.com> Fri, 14 May 2021 16:32 UTC

Return-Path: <ppsenak@cisco.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 4C4643A3844; Fri, 14 May 2021 09:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.297
X-Spam-Level:
X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZxHVfwJQTiDM; Fri, 14 May 2021 09:32:35 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D413A3841; Fri, 14 May 2021 09:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2837; q=dns/txt; s=iport; t=1621009955; x=1622219555; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=70pGrPMYSEVeXJqz+e0bYQeIg5SYTAu/4KrMdCz5X/0=; b=fZr1cZd9p7xTsgXLKRVqG6X1O8p2ZfjvZqaAe2/6K2QMpcKw/iHSZUUn omkmQ0Dat0MA00gJjoSM6/6bIZ7rwr7V79CTOrpvMiJGXv9LJ6dhn9JEf CuDpfeawk0GEUeA8GbEoccEIS2o980EIKKCvuoeFbZlyCKuH+Gcl1bLng c=;
X-IronPort-AV: E=Sophos;i="5.82,300,1613433600"; d="scan'208";a="36015822"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2021 16:32:33 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 14EGWWXn006130; Fri, 14 May 2021 16:32:32 GMT
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>
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>, Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "chopps@chopps.org" <chopps@chopps.org>
References: <161912242429.12485.17590245376033356793@ietfa.amsl.com> <CY4PR05MB357658E33E3CE2AFAE611690D5539@CY4PR05MB3576.namprd05.prod.outlook.com> <BY5PR11MB4337DA9E433B99F14413EE4CC1539@BY5PR11MB4337.namprd11.prod.outlook.com> <4a20282686224d84a76a53361117793f@huawei.com> <4688_1620805916_609B891C_4688_3_1_53C29892C857584299CBF5D05346208A4CD9BCDA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <0cd83802-7a40-2350-708d-8f0d15811129@cisco.com> <8582_1620807889_609B90D1_8582_438_1_53C29892C857584299CBF5D05346208A4CD9BE1B@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <63ff875d-b985-0cbb-6ac4-bc0c84d2e774@cisco.com> <8699_1620809033_609B9549_8699_452_1_53C29892C857584299CBF5D05346208A4CD9BF4E@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <ecbdb080-6af6-a2fe-811b-bf7b338e4ac6@cisco.com> <CAMMESsz-LbLnTVHbCBdQuk-vCbKditgekeH98+Z81-1s0qcx7g@mail.gmail.com> <BY5PR11MB43371711278F8A08D10CE446C1529@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <f894f86c-9921-c544-0828-49f84a704a0d@cisco.com>
Date: Fri, 14 May 2021 18:32:32 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <BY5PR11MB43371711278F8A08D10CE446C1529@BY5PR11MB4337.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/45rA_ELQ32IJzQunoWUENBB8Q-A>
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, 14 May 2021 16:32:42 -0000

Hi,

I'm fine with the below.

Do folks have any concerns with the below, or can I update the draft?

Please speak up if you disagree.

thanks,
Peter




On 12/05/2021 17:33, Les Ginsberg (ginsberg) wrote:
> Alvaro (and everyone) -
> 
> I think we can do better than this.
> 
> Prefix-attributes sub-TLV is necessary when a prefix is leaked between levels - and more specifically when leaked upwards in the hierarchy.
> (We have the "D" bit in the TLV itself when leaked downwards.)
> 
> While I would prefer that we simplify things and simply require the sub-TLV all the time, I think we can be more generous and still be functional.
> 
> 1)Prefix-attributes SHOULD be included in Locator TLV
> 2)Prefix-attributes MUST be included when TLV is leaked upwards in the hierarchy
> 3)Prefix-attributes sub-TLV MUST be included when the advertisement is "redistributed" from another protocol
> 
> Note that because the sub-TLV is not mandatory, if #2 and #3 are NOT followed, receivers will be unable to determine the correct source of the advertisement and may do the "wrong thing". And the receivers will be unable to detect the violation.
> 
> Finally, RFC 7794 was published over 5 years ago.
> Vendors make their own choices as to what protocol extensions they choose to support. But given the usefulness of the information in prefix-attributes sub-TLV I would encourage implementations which do not yet support the sub-TLV to add it.
> 
>     Les
> 
> 
>> -----Original Message-----
>> From: Alvaro Retana <aretana.ietf@gmail.com>
>> Sent: Wednesday, May 12, 2021 7:17 AM
>> To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; Peter
>> Psenak (ppsenak) <ppsenak@cisco.com>; bruno.decraene@orange.com
>> Cc: Van De Velde, Gunter (Nokia - BE/Antwerp)
>> <gunter.van_de_velde@nokia.com>; draft-ietf-lsr-isis-srv6-
>> extensions@ietf.org; Les Ginsberg (ginsberg) <ginsberg@cisco.com>;
>> Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>; lsr@ietf.org;
>> chopps@chopps.org
>> 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
>>
>> Peter:
>>
>>
>> Hi!
>>
>> As Xuesong suggested earlier, could you/we live with “SHOULD send”?
>> The mitigating circumstance (recommend vs require) is precisely the
>> lack of support.  I think your original reply to Gunter about how it
>> could be hard to mandate the Flags TLV at this point is spot on.
>>
>> Thanks!
>>
>> Alvaro.
>>
>>
>>
>> On May 12, 2021 at 4:49:58 AM, Peter Psenak wrote:
>>
>>> as I said, if we want to mandate the presence of the Prefix Attribute
>>> sub-TLV, we MUST ignore Locators without it. If we don't, then the MUST
>>> on the originator does not mean anything.
> 
>