Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Peter Psenak <> Fri, 13 October 2017 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0CDD1323F7; Fri, 13 Oct 2017 07:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r5ZVr-92_oTD; Fri, 13 Oct 2017 07:33:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A598120720; Fri, 13 Oct 2017 07:33:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4938; q=dns/txt; s=iport; t=1507905202; x=1509114802; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=xrCXoHGLDKl/j29WRC6wnSlOmEKDrs2X3Z2uMiazMlU=; b=GjSnacOwP+jTgNpA7ju6uX2+wvH7wreHPJfPMKtS6jxuJuqP0dvlL8nr ZSwm+zekMxmzQ3bah+/soYtSUE4DEqlKZzTnSltfg1LisRk9meVjh4YdD C2KMF0zj9KSm0DhdOpNnkFObbBXVPyvDa/6v2elwzp260A3zUAxgML5cq M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.43,371,1503360000"; d="scan'208";a="658064161"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Oct 2017 14:33:19 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v9DEXJW5001685; Fri, 13 Oct 2017 14:33:19 GMT
Message-ID: <>
Date: Fri, 13 Oct 2017 16:33:23 +0200
From: Peter Psenak <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Shraddha Hegde <>, "" <>, "" <>, "" <>
References: <> <6757_1507804395_59DF44EB_6757_192_1_9E32478DFA9976438E7A22F69B08FF921EA87066@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Oct 2017 14:33:25 -0000

Hi Shraddha,

please see inline:

On 13/10/17 15:49 , Shraddha Hegde wrote:
> Stephane,
> In certain cases MPLS forwarding may not be supported on some legacy linecards.

The problem you are describing is not SR specific, it would apply to LDP 
as well. So the indication should not be about SR, but about MPLS 
forwarding support on interface.

With MPLS being deployed for more then 20 years, I wonder why there was 
no need to solve this issue earlier and why we need to address it now 
with SR.

> Since these links should be used for IP forwarding IGPs will advertise these links.
> It is better to have explicit indication of this rather than use absence of adjacency-sid on the link.
> With the new SR flag, while the SPF and the SR-Path does not change, there is an indication
> To the controller and head-end nodes that the links cannot do SR-MPLS forwarding.
> The controller or head-end implementations may have mechanisms to prevent pulling
> Traffic on SR paths. When Head-end node detects a prefix-sid path going through such incapable links
> It may skip installing SR paths for such prefix-SID and implementations may decide to use other
> mechanisms (such as RSVP or IP) at the head-end which would prevent
> Traffic loss.
> This is also a useful tool during transition to SR when  certain links should avoid carrying SR traffic due to operational
> reasons.

there are standardized mechanisms like affinities that can be used to 
address above mentioned operational issue.


> Rgds
> Shraddha
> -----Original Message-----
> From: []
> Sent: Thursday, October 12, 2017 4:03 PM
> To:;
> Subject: RE: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
> Hi Authors,
> One question, why do you think it is really needed to introduce the SR flag ? Couldn't it be deduced from the presence of an Adj-SID and the SR router cap ?
> The SR flag unset while the router supports SR looks strange to me. Why do you want to prevent "SR forwarding" on a link if the node supports SR ?
> " With this information, a centralized
>     application can decide to use a different path for that traffic by
>     using a different label stack."
> In such a case, the usage of a Node-SID may be complex, as the Node-SID may cross a link with the SR flag unset. This will force the controller to use Adj-SIDs only.
> If the controller uses only Adj-SIDs, then an implementation can allow the user to prevent the advertisement of Adj-SIDs on a particular link.
> Could you clarify the use case here ?
> Thanks,
> -----Original Message-----
> From: Isis-wg [] On Behalf Of Christian Hopps
> Sent: Saturday, October 07, 2017 04:43
> To:
> Cc:;;
> Subject: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
> Hi Folks,
> The authors have requested the IS-IS WG adopt
> as a working group document. Please indicate your support or no-support for taking on this work.
> Authors: Please indicate your knowledge of any IPR related to this work to the list as well.
> Thanks,
> Chris & Hannes.
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> Isis-wg mailing list
> .