Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

Peter Psenak <ppsenak@cisco.com> Thu, 28 February 2019 19:56 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 B01F2130EFE; Thu, 28 Feb 2019 11:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vvbvy-63nytI; Thu, 28 Feb 2019 11:56:53 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5A5124BF6; Thu, 28 Feb 2019 11:56:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3659; q=dns/txt; s=iport; t=1551383813; x=1552593413; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yZ/K0FjA5udzeW66QCHrTO84vuyPO8bVnEhlCf60yn8=; b=hSPqw1rBF38Tpufl9vazGgHADhv1X56CoVucn6uMOevai3sGGtWWHJc7 peu0BHqpK+M60YSmS2sqWbqxWuPMh9rtkOOT+/2+WtcQF1eKD4sPO7vCz 5HRtPGAOntYh2oIgZ+y/Puxb9Opox+Ir9pP7ASonA982yQTYTM/cKxWdk g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAADwO3hc/xbLJq1lGQEBAQEBAQEBAQEBAQcBAQEBAQGBUwIBAQEBAQsBgmxxEieNAYx8mCAUgWcNGAuEA0YChDY2Bw0BAwEBAwEDAm0cDIVLAQEEAQE2NgsOAgsYLhYRMAYBDAYCAQGDHAGBcg+tXIQzAoEPhGcFBYxagUA/gRAogmuDHgEBA4EmBQESAUuFNQKJcYcykkcJh0KBGooIBhmBc4VfgyCIKopdhVaMaIFOATBlcTMaCBsVO4JsgigXiF+FQD4DMI1/gj4BAQ
X-IronPort-AV: E=Sophos;i="5.58,424,1544486400"; d="scan'208";a="10409662"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 19:56:50 +0000
Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x1SJunFu003598; Thu, 28 Feb 2019 19:56:49 GMT
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "draft-ietf-isis-segment-routing-extensions@ietf.org" <draft-ietf-isis-segment-routing-extensions@ietf.org>
References: <AM6PR03MB38302990EFFB7482B5C7F55F9D750@AM6PR03MB3830.eurprd03.prod.outlook.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "spring@ietf.org" <spring@ietf.org>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com>
Date: Thu, 28 Feb 2019 20:56:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <AM6PR03MB38302990EFFB7482B5C7F55F9D750@AM6PR03MB3830.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LTvkjLSL4LMjash46fNn57TRkNo>
Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs
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: Thu, 28 Feb 2019 19:56:56 -0000

Hi Alexander,

On 28/02/2019 19:19 , Alexander Vainshtein wrote:
> Dear colleagues,
>
> I have a question regarding global Adj-SIDs in
> draft-ietf-isis-segment-routing-extensions.
>
>
>
> Section 3.4 of RFC 8402 <https://tools.ietf.org/html/rfc8402>  defines
> definition and handling of global Adj-SIDs.
>
> The relevant text is given below:
>
>
>
> <quote>
>
>    Similarly, when using a global Adj-SID, a packet injected anywhere
>
>    within the SR domain with a segment list {SNL}, where SNL is a global
>
>    Adj-SID attached by node N to its adjacency over link L, will be
>
>    forwarded along the shortest path to Nand then be switched by N,
>
>    without any IP shortest-path consideration, towards link L.
>
> ...
>
>    The use of global Adj-SID allows to reduce the size of the segment list
>
>    When expressing a path at the cost of additional state (i.e., the global
>
>    Adj-SID will be inserted by all routers within the area in their
>
>    forwarding table).
>
> <end quote>
>
>
>
> The definition of the Adjacency Segment Identifier Sub-TLV in Section
> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it
> allows advertisement of global Adj-SIDs.
>
> These advertisements can be associated with a specific IGP adjacency
> and, in multi-topology scenarios, a specific topology. But it is not
> associated with any specific algorithm since the default algorithm for
> reaching the advertising node is implicitly assumed in full alignment
> with RFC 8402.
>
>
>
> My question is about the situation in which multiple algorithms are
> supported by the routers in the SR domain, so that each node advertises
> a dedicated Node SID for each of these algorithm.
>
> In this scenario, the operator can set up a SR-TE LSP that meets
> specific constraints (incorporated in one of these algorithms, see IGP
> Flexible Algorithm
> <https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-01> draft) by
> using Node SIDs that have been advertised with the corresponding
> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used
> (e.g., for reducing the label stack depth) in this situation.
>
> I wonder if the possibility to advertise global Adj-SID (that can be
> considered as replacing a combination of the Node SID of the advertising
> node and one of its local Adj-SIDs) as associated with a specific
> algorithm has ever been considered?

to be honest, it has been not.

The usage of the global Adj-SID has not been widely considered due to 
the additional forwarding entries it requires on rest of the routers in 
the area. Not sure if there are implementations of the global ADj-SID 
out there.

If you believe this is important, we can certainly addressed that in a 
small draft.

thanks,
Peter




>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>