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

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Tue, 11 May 2021 06:30 UTC

Return-Path: <gengxuesong@huawei.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 D1B7B3A10AC; Mon, 10 May 2021 23:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 vGpa6ETzkDp9; Mon, 10 May 2021 23:30:09 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63FD3A10AD; Mon, 10 May 2021 23:30:08 -0700 (PDT)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FfSRR6xkhz70gS4; Tue, 11 May 2021 14:18:43 +0800 (CST)
Received: from dggpemm100006.china.huawei.com (7.185.36.196) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 11 May 2021 08:29:58 +0200
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggpemm100006.china.huawei.com (7.185.36.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Tue, 11 May 2021 14:29:56 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.2176.012; Tue, 11 May 2021 14:29:56 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
CC: "chopps@chopps.org" <chopps@chopps.org>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Thread-Topic: [Lsr] Last Call: <draft-ietf-lsr-isis-srv6-extensions-14.txt> (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
Thread-Index: AQHXN7ROclxer8I2XUmrVwGhB/K93qrQ++CAgAAJAgCABpYVgIAAAfgAgAAwPYCABiFAcA==
Date: Tue, 11 May 2021 06:29:56 +0000
Message-ID: <83451aa2495a4098addf7c3d55fb0874@huawei.com>
References: <161912242429.12485.17590245376033356793@ietfa.amsl.com> <AM0PR07MB638668F6AC767504D0534925E05B9@AM0PR07MB6386.eurprd07.prod.outlook.com> <98456c8b-42dc-a387-0a18-f7921a94aeb1@cisco.com> <CAMMESsyzYoS=rR4RV1exdA-5DTMv6j2muNqrgWJ6oNocVgT0ug@mail.gmail.com> <MW3PR11MB4570139BCE708725E6BFD7C6C1579@MW3PR11MB4570.namprd11.prod.outlook.com> <BY5PR11MB43375E3E621FA59C8695E4F6C1579@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB43375E3E621FA59C8695E4F6C1579@BY5PR11MB4337.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.242.209]
Content-Type: multipart/alternative; boundary="_000_83451aa2495a4098addf7c3d55fb0874huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/obuvQ53O5ouMPkS-XYG8lln9KqU>
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: Tue, 11 May 2021 06:30:14 -0000

Hi Les,

Thanks for mentioning the compatibility issue. The prefix-attributes sub-TLV is not supported in the existing implementation of SRv6 ISIS in Huawei device.
So maybe we should be more cautious before deciding to change it from optional to mandatory.

Best
Xuesong

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, May 8, 2021 12:52 AM
To: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>; Alvaro Retana <aretana.ietf@gmail.com>; Peter Psenak (ppsenak) <ppsenak@cisco.com>; lsr@ietf.org
Cc: chopps@chopps.org; draft-ietf-lsr-isis-srv6-extensions@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
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

As has been mentioned in this thread, the need for the prefix-attributes sub-TLV to correctly process leaked advertisements is not unique to the Locator TLV. The reason prefix-attributes TLV was created was to address the same gap with IP/IPv6 reachability advertisements.
And I think by now implementations (certainly ones that support newer functionality like SRv6) should have added support for prefix-attributes sub-TLV .

In the case of the Locator TLV  – since this is new functionality – we have the option of mandating prefix-attributes sub-TLV – something we could not do with IP/IPv6 Reachability since that has been deployed for many years.

But,  please recognize two consequences of the MUST option:

1)Implementations may have to deal w  backwards compatibility w early deployments of SRv6. This would only be an issue if there are implementations that currently do NOT send prefix-attributes sub-TLV w Locator TLV.
Are there any such implementations??

2)In the case where the deployment is a single level, it could be argued that prefix-attributes sub-TLV isn’t needed.
I personally would NOT make such an argument, but we should understand that MUST applies to this case as well.

If everyone is OK with these consequences (personally I am OK) then I think it is fine to go with MUST.

   Les


From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, May 07, 2021 7:00 AM
To: Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org>
Cc: chopps@chopps.org<mailto:chopps@chopps.org>; draft-ietf-lsr-isis-srv6-extensions@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensions@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>
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

Hi Peter,

I agree that the support for the Prefix Attribute Flags TLV is required in the Locator TLV.

Thanks,
Ketan

From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Alvaro Retana
Sent: 07 May 2021 19:23
To: Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org>
Cc: chopps@chopps.org<mailto:chopps@chopps.org>; draft-ietf-lsr-isis-srv6-extensions@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensions@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>
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

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<mailto: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/
>